From gregghelt at gmail.com  Wed Oct  1 14:39:20 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 1 Oct 2008 11:39:20 -0700
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
Message-ID: <50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>

Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
temporary teleconference line if the one Ann is setting up isn't ready yet.

      Gregg

On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org> wrote:

> Thursday morning works for me as well.
>
>
> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>
>  I'm free most thursday after 12 noon eastern time, so that works for me.
>>
>> Lincoln
>>
>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com> wrote:
>>
>>  Hello again everybody!
>>>
>>> After taking an eight month sabbatical, I'm back to work (currently as a
>>> free agent).  In the last two months I've focused mainly on distributed
>>> annotation and DAS/2 in particular.  And although traffic on the list has
>>> been light/nonexistent, I know there are a number of others now actively
>>> working on DAS/2 servers and clients.  I'm hoping we can move the offline
>>> discussions we've been having back onto the list.
>>>
>>> I would also like to restart the DAS/2 teleconferences as soon as
>>> possible.
>>> Ann, is the offer to host these on your teleconference line still good?
>>> Would people be up for this Thursday morning (Pacific time) for the first
>>> one?  If not please propose a different time.  I think we should plan to
>>> devote most of the teleconference to a specific topic each time.  For the
>>> first one I'd like to do an overview of the current state of DAS/2 --
>>> spec,
>>> client/server/validator/registry implementations, deployments, who's
>>> working
>>> on what, etc.  After that here's my shortlist, please chime in with other
>>> possibilities:
>>>
>>>   Proposed spec changes -- DAS/2.1
>>>   Integration of DAS1 and DAS/2
>>>   Security / Authorization issues
>>>   Server implementations (Genometry, Biopackages, HapMap, Trellis (my new
>>> stuff))
>>>   Client implementations (IGB, ???)
>>>   Current state of distributed annotation in general
>>>   Integration of DAS/2 with GMOD
>>>
>>> Hope to talk with everyone soon,
>>> Gregg
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>
>>
>>
>> --
>> Lincoln D. Stein
>>
>> Ontario Institute for Cancer Research
>> 101 College St., Suite 800
>> Toronto, ON, Canada M5G0A3
>> 416 673-8514
>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>
>> Cold Spring Harbor Laboratory
>> 1 Bungtown Road
>> Cold Spring Harbor, NY 11724 USA
>> (516) 367-8380
>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>


From suzi at berkeleybop.org  Wed Oct  1 16:14:22 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 1 Oct 2008 14:14:22 -0600
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
Message-ID: <B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>

9am works for me

On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:

> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
> temporary teleconference line if the one Ann is setting up isn't  
> ready yet.
>
>      Gregg
>
> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis  
> <suzi at berkeleybop.org> wrote:
>
>> Thursday morning works for me as well.
>>
>>
>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>
>> I'm free most thursday after 12 noon eastern time, so that works  
>> for me.
>>>
>>> Lincoln
>>>
>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>  
>>> wrote:
>>>
>>> Hello again everybody!
>>>>
>>>> After taking an eight month sabbatical, I'm back to work  
>>>> (currently as a
>>>> free agent).  In the last two months I've focused mainly on  
>>>> distributed
>>>> annotation and DAS/2 in particular.  And although traffic on the  
>>>> list has
>>>> been light/nonexistent, I know there are a number of others now  
>>>> actively
>>>> working on DAS/2 servers and clients.  I'm hoping we can move the  
>>>> offline
>>>> discussions we've been having back onto the list.
>>>>
>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>> possible.
>>>> Ann, is the offer to host these on your teleconference line still  
>>>> good?
>>>> Would people be up for this Thursday morning (Pacific time) for  
>>>> the first
>>>> one?  If not please propose a different time.  I think we should  
>>>> plan to
>>>> devote most of the teleconference to a specific topic each time.   
>>>> For the
>>>> first one I'd like to do an overview of the current state of DAS/ 
>>>> 2 --
>>>> spec,
>>>> client/server/validator/registry implementations, deployments,  
>>>> who's
>>>> working
>>>> on what, etc.  After that here's my shortlist, please chime in  
>>>> with other
>>>> possibilities:
>>>>
>>>>  Proposed spec changes -- DAS/2.1
>>>>  Integration of DAS1 and DAS/2
>>>>  Security / Authorization issues
>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis  
>>>> (my new
>>>> stuff))
>>>>  Client implementations (IGB, ???)
>>>>  Current state of distributed annotation in general
>>>>  Integration of DAS/2 with GMOD
>>>>
>>>> Hope to talk with everyone soon,
>>>> Gregg
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
>>>
>>>
>>> --
>>> Lincoln D. Stein
>>>
>>> Ontario Institute for Cancer Research
>>> 101 College St., Suite 800
>>> Toronto, ON, Canada M5G0A3
>>> 416 673-8514
>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>
>>> Cold Spring Harbor Laboratory
>>> 1 Bungtown Road
>>> Cold Spring Harbor, NY 11724 USA
>>> (516) 367-8380
>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From aloraine at gmail.com  Wed Oct  1 16:26:31 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 1 Oct 2008 16:26:31 -0400
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
Message-ID: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>

Thank you Suzi. Let's use yours if it is not too much trouble.

The time got a little away from me and I haven't had a chance yet to
set up the line on our end.

9 am PST Thursday would be fine.

Best,

Ann

On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
> 9am works for me
>
> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>
>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
>> temporary teleconference line if the one Ann is setting up isn't ready
>> yet.
>>
>>     Gregg
>>
>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
>> wrote:
>>
>>> Thursday morning works for me as well.
>>>
>>>
>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>
>>> I'm free most thursday after 12 noon eastern time, so that works for me.
>>>>
>>>> Lincoln
>>>>
>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com> wrote:
>>>>
>>>> Hello again everybody!
>>>>>
>>>>> After taking an eight month sabbatical, I'm back to work (currently as
>>>>> a
>>>>> free agent).  In the last two months I've focused mainly on distributed
>>>>> annotation and DAS/2 in particular.  And although traffic on the list
>>>>> has
>>>>> been light/nonexistent, I know there are a number of others now
>>>>> actively
>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>> offline
>>>>> discussions we've been having back onto the list.
>>>>>
>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>> possible.
>>>>> Ann, is the offer to host these on your teleconference line still good?
>>>>> Would people be up for this Thursday morning (Pacific time) for the
>>>>> first
>>>>> one?  If not please propose a different time.  I think we should plan
>>>>> to
>>>>> devote most of the teleconference to a specific topic each time.  For
>>>>> the
>>>>> first one I'd like to do an overview of the current state of DAS/2 --
>>>>> spec,
>>>>> client/server/validator/registry implementations, deployments, who's
>>>>> working
>>>>> on what, etc.  After that here's my shortlist, please chime in with
>>>>> other
>>>>> possibilities:
>>>>>
>>>>>  Proposed spec changes -- DAS/2.1
>>>>>  Integration of DAS1 and DAS/2
>>>>>  Security / Authorization issues
>>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
>>>>> new
>>>>> stuff))
>>>>>  Client implementations (IGB, ???)
>>>>>  Current state of distributed annotation in general
>>>>>  Integration of DAS/2 with GMOD
>>>>>
>>>>> Hope to talk with everyone soon,
>>>>> Gregg
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lincoln D. Stein
>>>>
>>>> Ontario Institute for Cancer Research
>>>> 101 College St., Suite 800
>>>> Toronto, ON, Canada M5G0A3
>>>> 416 673-8514
>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>
>>>> Cold Spring Harbor Laboratory
>>>> 1 Bungtown Road
>>>> Cold Spring Harbor, NY 11724 USA
>>>> (516) 367-8380
>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From suzi at berkeleybop.org  Wed Oct  1 22:49:51 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 1 Oct 2008 20:49:51 -0600
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
	<83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
Message-ID: <4B514BC9-4F5B-4439-A228-0DBD2400E3CE@berkeleybop.org>

Okey-doke.

Here is the call in information, at least for tomorrow.

866-692-3582 4977624#

I don't know for certain how this works from the UK. If it pertains  
I'll dig deeper and find out, just speak up and let me know.

Talk to you all in the morn.

-S

On Oct 1, 2008, at 2:26 PM, Ann Loraine wrote:

> Thank you Suzi. Let's use yours if it is not too much trouble.
>
> The time got a little away from me and I haven't had a chance yet to
> set up the line on our end.
>
> 9 am PST Thursday would be fine.
>
> Best,
>
> Ann
>
> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>  
> wrote:
>> 9am works for me
>>
>> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>>
>>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set  
>>> up a
>>> temporary teleconference line if the one Ann is setting up isn't  
>>> ready
>>> yet.
>>>
>>>    Gregg
>>>
>>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis  
>>> <suzi at berkeleybop.org>
>>> wrote:
>>>
>>>> Thursday morning works for me as well.
>>>>
>>>>
>>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>>
>>>> I'm free most thursday after 12 noon eastern time, so that works  
>>>> for me.
>>>>>
>>>>> Lincoln
>>>>>
>>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt  
>>>>> <gregghelt at gmail.com> wrote:
>>>>>
>>>>> Hello again everybody!
>>>>>>
>>>>>> After taking an eight month sabbatical, I'm back to work  
>>>>>> (currently as
>>>>>> a
>>>>>> free agent).  In the last two months I've focused mainly on  
>>>>>> distributed
>>>>>> annotation and DAS/2 in particular.  And although traffic on  
>>>>>> the list
>>>>>> has
>>>>>> been light/nonexistent, I know there are a number of others now
>>>>>> actively
>>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>>> offline
>>>>>> discussions we've been having back onto the list.
>>>>>>
>>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>>> possible.
>>>>>> Ann, is the offer to host these on your teleconference line  
>>>>>> still good?
>>>>>> Would people be up for this Thursday morning (Pacific time) for  
>>>>>> the
>>>>>> first
>>>>>> one?  If not please propose a different time.  I think we  
>>>>>> should plan
>>>>>> to
>>>>>> devote most of the teleconference to a specific topic each  
>>>>>> time.  For
>>>>>> the
>>>>>> first one I'd like to do an overview of the current state of  
>>>>>> DAS/2 --
>>>>>> spec,
>>>>>> client/server/validator/registry implementations, deployments,  
>>>>>> who's
>>>>>> working
>>>>>> on what, etc.  After that here's my shortlist, please chime in  
>>>>>> with
>>>>>> other
>>>>>> possibilities:
>>>>>>
>>>>>> Proposed spec changes -- DAS/2.1
>>>>>> Integration of DAS1 and DAS/2
>>>>>> Security / Authorization issues
>>>>>> Server implementations (Genometry, Biopackages, HapMap, Trellis  
>>>>>> (my
>>>>>> new
>>>>>> stuff))
>>>>>> Client implementations (IGB, ???)
>>>>>> Current state of distributed annotation in general
>>>>>> Integration of DAS/2 with GMOD
>>>>>>
>>>>>> Hope to talk with everyone soon,
>>>>>> Gregg
>>>>>> _______________________________________________
>>>>>> DAS2 mailing list
>>>>>> DAS2 at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lincoln D. Stein
>>>>>
>>>>> Ontario Institute for Cancer Research
>>>>> 101 College St., Suite 800
>>>>> Toronto, ON, Canada M5G0A3
>>>>> 416 673-8514
>>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>>
>>>>> Cold Spring Harbor Laboratory
>>>>> 1 Bungtown Road
>>>>> Cold Spring Harbor, NY 11724 USA
>>>>> (516) 367-8380
>>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From lincoln.stein at gmail.com  Wed Oct  1 23:50:33 2008
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Wed, 1 Oct 2008 23:50:33 -0400
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
	<83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
Message-ID: <6dce9a0b0810012050l553ff7c2h24c175cceb37ab1b@mail.gmail.com>

Hi,

This will not work for me this week (tomorrow) because of a conflicting
conference call. Other weeks will be fine.

Lincoln

On Wed, Oct 1, 2008 at 4:26 PM, Ann Loraine <aloraine at gmail.com> wrote:

> Thank you Suzi. Let's use yours if it is not too much trouble.
>
> The time got a little away from me and I haven't had a chance yet to
> set up the line on our end.
>
> 9 am PST Thursday would be fine.
>
> Best,
>
> Ann
>
> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>
> wrote:
> > 9am works for me
> >
> > On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
> >
> >> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
> >> temporary teleconference line if the one Ann is setting up isn't ready
> >> yet.
> >>
> >>     Gregg
> >>
> >> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
> >> wrote:
> >>
> >>> Thursday morning works for me as well.
> >>>
> >>>
> >>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
> >>>
> >>> I'm free most thursday after 12 noon eastern time, so that works for
> me.
> >>>>
> >>>> Lincoln
> >>>>
> >>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>
> wrote:
> >>>>
> >>>> Hello again everybody!
> >>>>>
> >>>>> After taking an eight month sabbatical, I'm back to work (currently
> as
> >>>>> a
> >>>>> free agent).  In the last two months I've focused mainly on
> distributed
> >>>>> annotation and DAS/2 in particular.  And although traffic on the list
> >>>>> has
> >>>>> been light/nonexistent, I know there are a number of others now
> >>>>> actively
> >>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
> >>>>> offline
> >>>>> discussions we've been having back onto the list.
> >>>>>
> >>>>> I would also like to restart the DAS/2 teleconferences as soon as
> >>>>> possible.
> >>>>> Ann, is the offer to host these on your teleconference line still
> good?
> >>>>> Would people be up for this Thursday morning (Pacific time) for the
> >>>>> first
> >>>>> one?  If not please propose a different time.  I think we should plan
> >>>>> to
> >>>>> devote most of the teleconference to a specific topic each time.  For
> >>>>> the
> >>>>> first one I'd like to do an overview of the current state of DAS/2 --
> >>>>> spec,
> >>>>> client/server/validator/registry implementations, deployments, who's
> >>>>> working
> >>>>> on what, etc.  After that here's my shortlist, please chime in with
> >>>>> other
> >>>>> possibilities:
> >>>>>
> >>>>>  Proposed spec changes -- DAS/2.1
> >>>>>  Integration of DAS1 and DAS/2
> >>>>>  Security / Authorization issues
> >>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
> >>>>> new
> >>>>> stuff))
> >>>>>  Client implementations (IGB, ???)
> >>>>>  Current state of distributed annotation in general
> >>>>>  Integration of DAS/2 with GMOD
> >>>>>
> >>>>> Hope to talk with everyone soon,
> >>>>> Gregg
> >>>>> _______________________________________________
> >>>>> DAS2 mailing list
> >>>>> DAS2 at lists.open-bio.org
> >>>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Lincoln D. Stein
> >>>>
> >>>> Ontario Institute for Cancer Research
> >>>> 101 College St., Suite 800
> >>>> Toronto, ON, Canada M5G0A3
> >>>> 416 673-8514
> >>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
> >>>>
> >>>> Cold Spring Harbor Laboratory
> >>>> 1 Bungtown Road
> >>>> Cold Spring Harbor, NY 11724 USA
> >>>> (516) 367-8380
> >>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
> >>>> _______________________________________________
> >>>> DAS2 mailing list
> >>>> DAS2 at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>
> >>>>
> >>>
> >> _______________________________________________
> >> DAS2 mailing list
> >> DAS2 at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/das2
> >>
> >
> > _______________________________________________
> > DAS2 mailing list
> > DAS2 at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/das2
> >
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



-- 
Lincoln D. Stein

Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>

Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724 USA
(516) 367-8380
Assistant: Sandra Michelsen <michelse at cshl.edu>


From gregghelt at gmail.com  Thu Oct  2 08:57:40 2008
From: gregghelt at gmail.com (gregghelt at gmail.com)
Date: Thu, 02 Oct 2008 05:57:40 -0700
Subject: [DAS2] DAS/2 Grant Final Progress Report (submitted August 2008)
Message-ID: <0015175cde880f6df3045844c3c0@google.com>

For today's DAS/2 teleconference I'd like to focus on an overview of the  
current state of DAS/2. So for reference I've attached below the final  
progress report that I submitted for the NIH DAS/2 grant (with minor  
edits). Gregg


From gregghelt at gmail.com  Thu Oct  2 09:38:36 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 2 Oct 2008 06:38:36 -0700
Subject: [DAS2] DAS/2 Grant Final Progress Report (submitted August 2008)
In-Reply-To: <0015175cde880f6df3045844c3c0@google.com>
References: <0015175cde880f6df3045844c3c0@google.com>
Message-ID: <50158cb00810020638r534d865cr59331294631b5b09@mail.gmail.com>

Some people aren't seeing the HTML-ized text of the report, which should be
appended at the end of that last email.  So here's it is again attached as a
.doc file.

        Gregg

On Thu, Oct 2, 2008 at 5:57 AM, gregghelt at gmail.com <gregghelt at gmail.com>wrote:

>
> For today's DAS/2 teleconference I'd like to focus on an overview of the
> current state of DAS/2. So for reference I've attached below the final
> progress report that I submitted for the NIH DAS/2 grant (with minor edits).
>
> Gregg
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DAS_2_Final_Progress_Report_Aug_2008_revised.doc
Type: application/msword
Size: 130048 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/das2/attachments/20081002/e442682f/attachment.doc>

From Steve_Chervitz at affymetrix.com  Thu Oct  2 13:39:19 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 02 Oct 2008 10:39:19 -0700
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <6dce9a0b0810012050l553ff7c2h24c175cceb37ab1b@mail.gmail.com>
Message-ID: <C50A5557.3242A%Steve_Chervitz@affymetrix.com>

This time will normally work for me, and I can post meeting notes, as I have
done in the past, though not for today's call (sorry to miss out).

How frequent should these meetings be? Maybe weekly would be best during
this rev-up period, then transition to monthly after things stabilize?

If someone could post any notes from the meeting, that would be great.

Steve


> From: Lincoln Stein <lincoln.stein at gmail.com>
> Date: Wed, 1 Oct 2008 23:50:33 -0400
> To: Ann Loraine <aloraine at gmail.com>
> Cc: <das2 at lists.open-bio.org>
> Subject: Re: [DAS2] Restarting DAS/2 teleconferences?
> 
> Hi,
> 
> This will not work for me this week (tomorrow) because of a conflicting
> conference call. Other weeks will be fine.
> 
> Lincoln
> 
> On Wed, Oct 1, 2008 at 4:26 PM, Ann Loraine <aloraine at gmail.com> wrote:
> 
>> Thank you Suzi. Let's use yours if it is not too much trouble.
>> 
>> The time got a little away from me and I haven't had a chance yet to
>> set up the line on our end.
>> 
>> 9 am PST Thursday would be fine.
>> 
>> Best,
>> 
>> Ann
>> 
>> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>
>> wrote:
>>> 9am works for me
>>> 
>>> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>>> 
>>>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
>>>> temporary teleconference line if the one Ann is setting up isn't ready
>>>> yet.
>>>> 
>>>>     Gregg
>>>> 
>>>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
>>>> wrote:
>>>> 
>>>>> Thursday morning works for me as well.
>>>>> 
>>>>> 
>>>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>>> 
>>>>> I'm free most thursday after 12 noon eastern time, so that works for
>> me.
>>>>>> 
>>>>>> Lincoln
>>>>>> 
>>>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>
>> wrote:
>>>>>> 
>>>>>> Hello again everybody!
>>>>>>> 
>>>>>>> After taking an eight month sabbatical, I'm back to work (currently
>> as
>>>>>>> a
>>>>>>> free agent).  In the last two months I've focused mainly on
>> distributed
>>>>>>> annotation and DAS/2 in particular.  And although traffic on the list
>>>>>>> has
>>>>>>> been light/nonexistent, I know there are a number of others now
>>>>>>> actively
>>>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>>>> offline
>>>>>>> discussions we've been having back onto the list.
>>>>>>> 
>>>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>>>> possible.
>>>>>>> Ann, is the offer to host these on your teleconference line still
>> good?
>>>>>>> Would people be up for this Thursday morning (Pacific time) for the
>>>>>>> first
>>>>>>> one?  If not please propose a different time.  I think we should plan
>>>>>>> to
>>>>>>> devote most of the teleconference to a specific topic each time.  For
>>>>>>> the
>>>>>>> first one I'd like to do an overview of the current state of DAS/2 --
>>>>>>> spec,
>>>>>>> client/server/validator/registry implementations, deployments, who's
>>>>>>> working
>>>>>>> on what, etc.  After that here's my shortlist, please chime in with
>>>>>>> other
>>>>>>> possibilities:
>>>>>>> 
>>>>>>>  Proposed spec changes -- DAS/2.1
>>>>>>>  Integration of DAS1 and DAS/2
>>>>>>>  Security / Authorization issues
>>>>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
>>>>>>> new
>>>>>>> stuff))
>>>>>>>  Client implementations (IGB, ???)
>>>>>>>  Current state of distributed annotation in general
>>>>>>>  Integration of DAS/2 with GMOD
>>>>>>> 
>>>>>>> Hope to talk with everyone soon,
>>>>>>> Gregg
>>>>>>> _______________________________________________
>>>>>>> DAS2 mailing list
>>>>>>> DAS2 at lists.open-bio.org
>>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Lincoln D. Stein
>>>>>> 
>>>>>> Ontario Institute for Cancer Research
>>>>>> 101 College St., Suite 800
>>>>>> Toronto, ON, Canada M5G0A3
>>>>>> 416 673-8514
>>>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>>> 
>>>>>> Cold Spring Harbor Laboratory
>>>>>> 1 Bungtown Road
>>>>>> Cold Spring Harbor, NY 11724 USA
>>>>>> (516) 367-8380
>>>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>>>> _______________________________________________
>>>>>> DAS2 mailing list
>>>>>> DAS2 at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>> 
>>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>> 
>>> 
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>> 
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>> 
> 
> 
> 
> -- 
> Lincoln D. Stein
> 
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
> 
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724 USA
> (516) 367-8380
> Assistant: Sandra Michelsen <michelse at cshl.edu>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2

------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.


From jw12 at sanger.ac.uk  Wed Oct  8 09:34:59 2008
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 08 Oct 2008 14:34:59 +0100
Subject: [DAS2] DAS workshop 2009
Message-ID: <1223472899.3418.83.camel@deskpro20727.dynamic.sanger.ac.uk>

We are considering running a DAS workshop here at the Sanger in the UK
in 2009 subject to decent demand.

If would be interested in attending either to present or just take part
then please email me jw12 at sanger.ac.uk

For further details please see the news items section at the top of
www.dasregistry.org

Thanks

Jonathan.



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 


From John.Nicol at uncc.edu  Tue Oct 14 14:36:54 2008
From: John.Nicol at uncc.edu (Nicol, John)
Date: Tue, 14 Oct 2008 14:36:54 -0400
Subject: [DAS2] DAS/2 specification problems
Message-ID: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>

Hi all,

I'm looking at the DAS/2 specification (at, say, http://biodas.org/documents/das2/das2_get.html), and I'm encountering some problems.

Specifically, none of the biodas links appear to work.  These would be useful to do some verifications on our server.
http://www.biodas.org/das/sequence/gallus_gallus/March2004/types
http://www.biodas.org/known_das_servers
http://www.biodas.org/sequence/s.cerevisiae/genes.xml

Many of the other links don't work.  For example:
http://dev.wormbase.org/das/genome/  (which itself links to the unknown http://www.biodas.org/das2)
http://www.ensembl.org/Homo_sapiens/Chr1
http://das.ensembl.org/das/SPICEDS/127/
http://sanger.ac.uk/das-registry/yeast-32-chromosome
http://flybase.org/genome/D_melanogaster/R4.3/dna/X
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4

And here's a typo:
http://ensemble.org/Homo_sapiens/Chr1

Thanks!
John




From andy.jenkinson at ebi.ac.uk  Wed Oct 15 09:28:30 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 15 Oct 2008 14:28:30 +0100
Subject: [DAS2] teleconference
Message-ID: <48F5EFFE.2040901@ebi.ac.uk>

Hi all,

Is there to be another teleconference tomorrow?

Andy


From gregghelt at gmail.com  Wed Oct 15 11:47:46 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 08:47:46 -0700
Subject: [DAS2] teleconference
In-Reply-To: <48F5EFFE.2040901@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
Message-ID: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>

Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?  If
not then Suzi can we use yours again?

Possible topics:
     DAS 1/2/etc. integration
     Security and authorization
     Proposed specification changes

If anyone has a preference for one of the above, or wants to propose another
topic, please post.

       thanks,
       Gregg

On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Hi all,
>
> Is there to be another teleconference tomorrow?
>
> Andy
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From aloraine at gmail.com  Wed Oct 15 11:49:44 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 15 Oct 2008 11:49:44 -0400
Subject: [DAS2] [DAS] teleconference
In-Reply-To: <48F5EFFE.2040901@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
Message-ID: <83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>

Dear all,

During our last conference call, we discussed having a teleconference
every two weeks.

What do you think about instead convening on a more ad hoc basis,
using the list for day-to-day communications?

Sincerely,

Ann

On Wed, Oct 15, 2008 at 9:28 AM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk> wrote:
> Hi all,
>
> Is there to be another teleconference tomorrow?
>
> Andy
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>


From suzi at berkeleybop.org  Wed Oct 15 12:21:04 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 12:21:04 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
Message-ID: <9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>

Gregg I'm on the line if anyone is still available.

On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:

> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set  
> up?  If
> not then Suzi can we use yours again?
>
> Possible topics:
>     DAS 1/2/etc. integration
>     Security and authorization
>     Proposed specification changes
>
> If anyone has a preference for one of the above, or wants to propose  
> another
> topic, please post.
>
>       thanks,
>       Gregg
>
> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> Hi all,
>>
>> Is there to be another teleconference tomorrow?
>>
>> Andy
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From andy.jenkinson at ebi.ac.uk  Wed Oct 15 12:24:11 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 15 Oct 2008 17:24:11 +0100
Subject: [DAS2] teleconference
In-Reply-To: <9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
Message-ID: <48F6192B.5070401@ebi.ac.uk>

This is supposed to be tomorrow (Thursday) right?

Suzanna Lewis wrote:
> Gregg I'm on the line if anyone is still available.
> 
> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
> 
>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set 
>> up?  If
>> not then Suzi can we use yours again?
>>
>> Possible topics:
>>     DAS 1/2/etc. integration
>>     Security and authorization
>>     Proposed specification changes
>>
>> If anyone has a preference for one of the above, or wants to propose 
>> another
>> topic, please post.
>>
>>       thanks,
>>       Gregg
>>
>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson 
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>> Hi all,
>>>
>>> Is there to be another teleconference tomorrow?
>>>
>>> Andy
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>


From jw12 at sanger.ac.uk  Wed Oct 15 12:28:11 2008
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 15 Oct 2008 17:28:11 +0100
Subject: [DAS2] Spec Review
Message-ID: <1224088091.5029.60.camel@deskpro20727.dynamic.sanger.ac.uk>

Further to Andy's email below, we have written a spec review document at
http://www.biodas.org/wiki/Spec_Review, which is still a work in
progress as the DAS spec will probably always be to a degree.

To reiterate, this  document is  "to make the document more consistent
with common usage and add official support for the "sources" metadata
command (from 1.53E and DAS/2) and to reduce complexity and confusion by
removing unused features." It's editable (if you register with the site
and log in). So we encourage people to either edit or make suggestions
via the das email lists.

We have also created another document so we can all propose new
extensions and ways forward to improve the above "consolidated" spec at
http://www.biodas.org/wiki/DAS_Plans

Cheers

Joanthan. 








------------------------------------------------------------

Hi all,

Over the last couple of weeks there have been a few meetings on the
Hinxton campus aimed at exploring options for reconciling the two
versions of the DAS spec. Involved were myself, Gregg Helt, Jonathan
Warren, Felix Kokocinski, Phil Jones, Henning Hermjakob and Tim Hubbard.

As a first step we have conducted a review of the current 1.53 spec with
a view to updating it. The aim is to make the document more consistent
with common usage, add official support for the "sources" metadata
command (from 1.53E and DAS/2) and to reduce complexity and confusion by
removing unused features. Another mail will be sent out soon with the
conclusions so that they can be discussed before any changes are made.

Cheers,
Andy



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 


From suzi at berkeleybop.org  Wed Oct 15 12:15:02 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 12:15:02 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
Message-ID: <2718D4AE-F29C-4FF3-986D-9F2C4C81C90E@berkeleybop.org>

Gregg, you all must be on the call already (yes, using my line is  
okay), but I'm caught up in the course here and can't make the call  
myself.

-S

On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:

> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set  
> up?  If
> not then Suzi can we use yours again?
>
> Possible topics:
>     DAS 1/2/etc. integration
>     Security and authorization
>     Proposed specification changes
>
> If anyone has a preference for one of the above, or wants to propose  
> another
> topic, please post.
>
>       thanks,
>       Gregg
>
> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> Hi all,
>>
>> Is there to be another teleconference tomorrow?
>>
>> Andy
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From gregghelt at gmail.com  Wed Oct 15 13:12:52 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:12:52 -0700
Subject: [DAS2] teleconference
In-Reply-To: <48F6192B.5070401@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
	<48F6192B.5070401@ebi.ac.uk>
Message-ID: <50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>

Yes the conference call is tomorrow (Thursday) at 9 AM Pacific time.  Sorry
for any confusion.

      Gregg

On Wed, Oct 15, 2008 at 9:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> This is supposed to be tomorrow (Thursday) right?
>
>
> Suzanna Lewis wrote:
>
>> Gregg I'm on the line if anyone is still available.
>>
>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>
>>  Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>>  If
>>> not then Suzi can we use yours again?
>>>
>>> Possible topics:
>>>    DAS 1/2/etc. integration
>>>    Security and authorization
>>>    Proposed specification changes
>>>
>>> If anyone has a preference for one of the above, or wants to propose
>>> another
>>> topic, please post.
>>>
>>>      thanks,
>>>      Gregg
>>>
>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <
>>> andy.jenkinson at ebi.ac.uk>wrote:
>>>
>>>  Hi all,
>>>>
>>>> Is there to be another teleconference tomorrow?
>>>>
>>>> Andy
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>  _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>


From gregghelt at gmail.com  Wed Oct 15 13:18:39 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:18:39 -0700
Subject: [DAS2] [DAS] teleconference
In-Reply-To: <83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>
Message-ID: <50158cb00810151018x4d342dem71a559e0864f4a04@mail.gmail.com>

I think we really need to have a regularly scheduled teleconference every
two weeks, rather than ad-hoc.  If we focus on one or two topics each
teleconference people who can't attend every time can join in for those
they're most interested in.

      Gregg

On Wed, Oct 15, 2008 at 8:49 AM, Ann Loraine <aloraine at gmail.com> wrote:

> Dear all,
>
> During our last conference call, we discussed having a teleconference
> every two weeks.
>
> What do you think about instead convening on a more ad hoc basis,
> using the list for day-to-day communications?
>
> Sincerely,
>
> Ann
>
> On Wed, Oct 15, 2008 at 9:28 AM, Andy Jenkinson
> <andy.jenkinson at ebi.ac.uk> wrote:
> > Hi all,
> >
> > Is there to be another teleconference tomorrow?
> >
> > Andy
> > _______________________________________________
> > 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
>


From suzi at berkeleybop.org  Wed Oct 15 13:23:33 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 13:23:33 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
	<48F6192B.5070401@ebi.ac.uk>
	<50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>
Message-ID: <D4C53145-B396-4347-8E8F-83349FAE4A69@berkeleybop.org>

I might be a bit late for tomorrow (wrapping up a lecture), but should  
be able to get on.

Gregg do you have all of the call in information? Or should I send  
this to you again?

-S

On Oct 15, 2008, at 1:12 PM, Gregg Helt wrote:

> Yes the conference call is tomorrow (Thursday) at 9 AM Pacific  
> time.  Sorry
> for any confusion.
>
>      Gregg
>
> On Wed, Oct 15, 2008 at 9:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> This is supposed to be tomorrow (Thursday) right?
>>
>>
>> Suzanna Lewis wrote:
>>
>>> Gregg I'm on the line if anyone is still available.
>>>
>>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>>
>>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line  
>>> set up?
>>>> If
>>>> not then Suzi can we use yours again?
>>>>
>>>> Possible topics:
>>>>   DAS 1/2/etc. integration
>>>>   Security and authorization
>>>>   Proposed specification changes
>>>>
>>>> If anyone has a preference for one of the above, or wants to  
>>>> propose
>>>> another
>>>> topic, please post.
>>>>
>>>>     thanks,
>>>>     Gregg
>>>>
>>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <
>>>> andy.jenkinson at ebi.ac.uk>wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> Is there to be another teleconference tomorrow?
>>>>>
>>>>> Andy
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From aloraine at gmail.com  Wed Oct 15 13:24:31 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 15 Oct 2008 13:24:31 -0400
Subject: [DAS2] setting up DAS conference, was: Re:  teleconference
Message-ID: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>

Hi all,

I just talked to the telecom support at UNC Charlotte.

I reserved a time for us to use a conference call line
("Meet-me-conf") at the University starting 12 pm EST.

The number everybody would call is: 704-687-8984.

There's a little complication in that somebody on campus will have to
initiate the call for me, but I think I can find somebody to help out
with that aspect.

-Ann


On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
> Gregg, you all must be on the call already (yes, using my line is okay), but
> I'm caught up in the course here and can't make the call myself.
>
> -S
>
> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>
>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>  If
>> not then Suzi can we use yours again?
>>
>> Possible topics:
>>    DAS 1/2/etc. integration
>>    Security and authorization
>>    Proposed specification changes
>>
>> If anyone has a preference for one of the above, or wants to propose
>> another
>> topic, please post.
>>
>>      thanks,
>>      Gregg
>>
>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>> Hi all,
>>>
>>> Is there to be another teleconference tomorrow?
>>>
>>> Andy
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From gregghelt at gmail.com  Wed Oct 15 13:46:37 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:46:37 -0700
Subject: [DAS2] DAS/2 specification problems
In-Reply-To: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>
References: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>
Message-ID: <50158cb00810151046t1cdcdb95j9cac88d342d465c8@mail.gmail.com>

Apologies, most of the XML responses in the DAS/2 protocol specification are
only examples, not responses from actual servers.  We could change this so
that the spec uses example from working servers.  However, none of the
currently deployed DAS/2 servers that I know of exercise every optional
element and attribute of the spec, so they would be incomplete examples.
But the spec HTML docs are definitely due for an overhaul...

Here's the overview page for the main Affymetrix DAS/2 server, with example
sources, types, segments, and features queries:
    http://netaffxdas.affymetrix.com/das2

Also, at least one of the URLs you list is not guaranteed to be resolvable:
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4
This is given as the value for the uri attribute of a COORDINATES element.
These URIs MAY be resolvable but do not have to be.

In general as part of a spec revision (DAS 2.1?) I'd like to eliminate more
of the resolvability requirements in the specification, and specify that
most URIs be used as identifiers with _optional_ resolvability.  After two
years of working with the current spec I've come to believe that for most
cases requiring URI resolution is not necessary, places added burden on
server implementations, and limits the ability to do non-authoritative
decentralized annotation.

     sincerely,
     Gregg

On Tue, Oct 14, 2008 at 11:36 AM, Nicol, John <John.Nicol at uncc.edu> wrote:

> Hi all,
>
> I'm looking at the DAS/2 specification (at, say,
> http://biodas.org/documents/das2/das2_get.html), and I'm encountering some
> problems.
>
> Specifically, none of the biodas links appear to work.  These would be
> useful to do some verifications on our server.
> http://www.biodas.org/das/sequence/gallus_gallus/March2004/types
> http://www.biodas.org/known_das_servers
> http://www.biodas.org/sequence/s.cerevisiae/genes.xml
>
> Many of the other links don't work.  For example:
> http://dev.wormbase.org/das/genome/  (which itself links to the unknown
> http://www.biodas.org/das2)
> http://www.ensembl.org/Homo_sapiens/Chr1
> http://das.ensembl.org/das/SPICEDS/127/
> http://sanger.ac.uk/das-registry/yeast-32-chromosome
> http://flybase.org/genome/D_melanogaster/R4.3/dna/X
> http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4
>
> And here's a typo:
> http://ensemble.org/Homo_sapiens/Chr1
>
> Thanks!
> John
>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From aloraine at gmail.com  Thu Oct 16 10:04:20 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Thu, 16 Oct 2008 10:04:20 -0400
Subject: [DAS2] setting up DAS conference, was: Re:  teleconference
In-Reply-To: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
References: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
Message-ID: <83722dde0810160704g7adca679m7b80512ae8d59f7f@mail.gmail.com>

Dear all,

The conference call for today is confirmed -- please call:

704-687-8984

at noon, EST (9 am PST)

Best,

Ann

On Wed, Oct 15, 2008 at 1:24 PM, Ann Loraine <aloraine at gmail.com> wrote:
> Hi all,
>
> I just talked to the telecom support at UNC Charlotte.
>
> I reserved a time for us to use a conference call line
> ("Meet-me-conf") at the University starting 12 pm EST.
>
> The number everybody would call is: 704-687-8984.
>
> There's a little complication in that somebody on campus will have to
> initiate the call for me, but I think I can find somebody to help out
> with that aspect.
>
> -Ann
>
>
> On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
>> Gregg, you all must be on the call already (yes, using my line is okay), but
>> I'm caught up in the course here and can't make the call myself.
>>
>> -S
>>
>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>
>>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>>  If
>>> not then Suzi can we use yours again?
>>>
>>> Possible topics:
>>>    DAS 1/2/etc. integration
>>>    Security and authorization
>>>    Proposed specification changes
>>>
>>> If anyone has a preference for one of the above, or wants to propose
>>> another
>>> topic, please post.
>>>
>>>      thanks,
>>>      Gregg
>>>
>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
>>> <andy.jenkinson at ebi.ac.uk>wrote:
>>>
>>>> Hi all,
>>>>
>>>> Is there to be another teleconference tomorrow?
>>>>
>>>> Andy
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>


From gregghelt at gmail.com  Thu Oct 16 10:37:21 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 16 Oct 2008 07:37:21 -0700
Subject: [DAS2] Fwd: setting up DAS conference, was: Re:  teleconference
In-Reply-To: <50158cb00810160736v208049au70702e57d18f871c@mail.gmail.com>
References: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
	<83722dde0810160704g7adca679m7b80512ae8d59f7f@mail.gmail.com>
	<50158cb00810160736v208049au70702e57d18f871c@mail.gmail.com>
Message-ID: <50158cb00810160737h329a4b91v469fc4d9487397fe@mail.gmail.com>

---------- Forwarded message ----------
From: Gregg Helt <gregghelt at gmail.com>
Date: Thu, Oct 16, 2008 at 7:36 AM
Subject: Re: setting up DAS conference, was: Re: [DAS2] teleconference
To: Ann Loraine <aloraine at gmail.com>


Is there a conference ID that needs to be entered?
Also is there a toll-free number?  An international number?

     thanks!
     Gregg


On Thu, Oct 16, 2008 at 7:04 AM, Ann Loraine <aloraine at gmail.com> wrote:

> Dear all,
>
> The conference call for today is confirmed -- please call:
>
> 704-687-8984
>
> at noon, EST (9 am PST)
>
> Best,
>
> Ann
>
> On Wed, Oct 15, 2008 at 1:24 PM, Ann Loraine <aloraine at gmail.com> wrote:
> > Hi all,
> >
> > I just talked to the telecom support at UNC Charlotte.
> >
> > I reserved a time for us to use a conference call line
> > ("Meet-me-conf") at the University starting 12 pm EST.
> >
> > The number everybody would call is: 704-687-8984.
> >
> > There's a little complication in that somebody on campus will have to
> > initiate the call for me, but I think I can find somebody to help out
> > with that aspect.
> >
> > -Ann
> >
> >
> > On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org>
> wrote:
> >> Gregg, you all must be on the call already (yes, using my line is okay),
> but
> >> I'm caught up in the course here and can't make the call myself.
> >>
> >> -S
> >>
> >> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
> >>
> >>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set
> up?
> >>>  If
> >>> not then Suzi can we use yours again?
> >>>
> >>> Possible topics:
> >>>    DAS 1/2/etc. integration
> >>>    Security and authorization
> >>>    Proposed specification changes
> >>>
> >>> If anyone has a preference for one of the above, or wants to propose
> >>> another
> >>> topic, please post.
> >>>
> >>>      thanks,
> >>>      Gregg
> >>>
> >>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
> >>> <andy.jenkinson at ebi.ac.uk>wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Is there to be another teleconference tomorrow?
> >>>>
> >>>> Andy
> >>>> _______________________________________________
> >>>> DAS2 mailing list
> >>>> DAS2 at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>
> >>> _______________________________________________
> >>> DAS2 mailing list
> >>> DAS2 at lists.open-bio.org
> >>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>
> >>
> >> _______________________________________________
> >> DAS2 mailing list
> >> DAS2 at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/das2
> >>
> >
>


From gregghelt at gmail.com  Tue Oct 28 14:02:37 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Tue, 28 Oct 2008 11:02:37 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
Message-ID: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>

I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
framework, and Ivy is the DAS1 proxy plugin.  The source code is available
via SVN at http://code.google.com/p/genomancer/ .  This should definitely be
considered a beta release, there are plenty of features that aren't yet
implemented and I'm sure still some bugs in what is implemented.

I'm hoping a stable version of this can eventually be set up close to or
integrated with the DAS1 registry.  For current testing I've deployed an
instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
hardwired to proxy for the Sanger DAS1
registry<http://www.dasregistry.org/das1/sources>.
Some example DAS2 queries and the DAS1 queries they proxy for:

All DAS1 registry sources:
http://www.dasregistry.org/das1/sources
All DAS1 registry sources --> DAS1+2 sources
http://www.genomancer.org/das2/das1_proxy/sources

DAS1 filtered sources
http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
DAS1 filtered sources --> DAS1+2 filtered sources
http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types

Ensembl DAS1 entry points
http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
Ensembl DAS1 entry points --> DAS2 segments
http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points

Uniprot DAS1 types
http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
Uniprot DAS1 types --> DAS2 types:
http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types

Uniprot DAS1 features (from UniProt DAS home page example)
http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
UniProt DAS1 features --> DAS2 features
http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502

Ensembl DAS1 features (from Ensembl DAS home page example)
http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
Ensembl DAS1 features --> DAS2 features
http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806

UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
request (copied from IGB testing):
http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene


Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
    DAS1 sequence --> DAS2 segments
    DAS1 dsn --> DAS2 sources
    DAS1 stylesheet --> DAS2 stylesheet
I'll post a summary of plans for these queries and other features soon, but
I wanted to at least send out this announcement so people who are interested
can check out the examples.  Please let me know what you think.

    Gregg


From gilmanb at pantherinformatics.com  Tue Oct 28 14:18:05 2008
From: gilmanb at pantherinformatics.com (Brian Gilman)
Date: Tue, 28 Oct 2008 14:18:05 -0400
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
Message-ID: <FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>

Greg,

	Can I use the DAS2 server framework to write the Haploview service?

-B
--
Brian Gilman
President Panther Informatics Inc.
E-Mail: gilmanb at pantherinformatics.com
         gilmanb at jforge.net
AIM: gilmanb1

<a href="www.scilink.com/people/gilmanb"><img src="http://www.scilink.com/images/buttons/scilink_viewmy_black.png 
"/></a>


On Oct 28, 2008, at 2:02 PM, Gregg Helt wrote:

> I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2  
> server
> framework, and Ivy is the DAS1 proxy plugin.  The source code is  
> available
> via SVN at http://code.google.com/p/genomancer/ .  This should  
> definitely be
> considered a beta release, there are plenty of features that aren't  
> yet
> implemented and I'm sure still some bugs in what is implemented.
>
> I'm hoping a stable version of this can eventually be set up close  
> to or
> integrated with the DAS1 registry.  For current testing I've  
> deployed an
> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.   
> It's
> hardwired to proxy for the Sanger DAS1
> registry<http://www.dasregistry.org/das1/sources>.
> Some example DAS2 queries and the DAS1 queries they proxy for:
>
> All DAS1 registry sources:
> http://www.dasregistry.org/das1/sources
> All DAS1 registry sources --> DAS1+2 sources
> http://www.genomancer.org/das2/das1_proxy/sources
>
> DAS1 filtered sources
> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
> DAS1 filtered sources --> DAS1+2 filtered sources
> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>
> Ensembl DAS1 entry points
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
> Ensembl DAS1 entry points --> DAS2 segments
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>
> Uniprot DAS1 types
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
> Uniprot DAS1 types --> DAS2 types:
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>
> Uniprot DAS1 features (from UniProt DAS home page example)
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
> UniProt DAS1 features --> DAS2 features
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>
> Ensembl DAS1 features (from Ensembl DAS home page example)
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
> Ensembl DAS1 features --> DAS2 features
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>
> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
> request (copied from IGB testing):
> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>
>
> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>    DAS1 sequence --> DAS2 segments
>    DAS1 dsn --> DAS2 sources
>    DAS1 stylesheet --> DAS2 stylesheet
> I'll post a summary of plans for these queries and other features  
> soon, but
> I wanted to at least send out this announcement so people who are  
> interested
> can check out the examples.  Please let me know what you think.
>
>    Gregg
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From gregghelt at gmail.com  Tue Oct 28 14:58:54 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Tue, 28 Oct 2008 11:58:54 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
	<FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>
Message-ID: <50158cb00810281158h60fe4f0bsdd9b8993c1c2972b@mail.gmail.com>

Yes, I was actually thinking of the HapMap DAS/2 server as one potential
project.  I'd definitely be interested in helping!

In the Trellis source code there's a Trellis DAS/2 data model API in package
genomancer.trellis.das2.model.  These Java interfaces are based on a UML
model -- I'll try to post the UML later today.  Plugins for particular data
backends need to implement the
genomancer.trellis.das2.server.TrellisSourcesPluginI interface, which in
turn relies on the plugin having implementations of the DAS/2 data model.
Trellis is a Java servlet, and you configure Trellis to use a plugin by
setting the TrellisDas2Servlet "sources_plugin_class" init-param, either
programatically or via configuration in the web application deployment
descriptor.

Currently there are two Trellis-based servers in the genomancer source code,
a DAS2-->DAS2 proxy (genomancer.vine.das2.proxy.JettyDas2ProxyServer) and a
DAS1-->DAS2 proxy (genomancer.ivy.das2.proxy.JettyDas1ProxyServer).  Both of
these use Jetty for the HTTP server and servlet container, and have the
plugin hardcoded as well as a hardcoded localhost address and port.  I plan
to have more general examples using Tomcat and standard web app deployment
descriptors by the end of the week.

For my implementations of the Trellis DAS/2 data model, many of the classes
are really data structs with little or no behavior, and just setter/getter
methods.  If you don't want to reimplement the whole data model for these
data-struct classes you should be able to reuse the implementations in the
Vine DAS2 proxy plugin (genomancer.vine.das2.client.modelimpl).  It's the
higher-level parts of the model (particularly the Das2***CapabilityI
interfaces) that will likely need custom implementations for each plugin.

      Gregg

On Tue, Oct 28, 2008 at 11:18 AM, Brian Gilman <
gilmanb at pantherinformatics.com> wrote:

> Greg,
>
>        Can I use the DAS2 server framework to write the Haploview service?
>
> -B
> --
> Brian Gilman
> President Panther Informatics Inc.
> E-Mail: gilmanb at pantherinformatics.com
>        gilmanb at jforge.net
> AIM: gilmanb1
>
> <a href="www.scilink.com/people/gilmanb"><img src="
> http://www.scilink.com/images/buttons/scilink_viewmy_black.png"/></a>
>
>
> On Oct 28, 2008, at 2:02 PM, Gregg Helt wrote:
>
>  I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
>> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
>> framework, and Ivy is the DAS1 proxy plugin.  The source code is available
>> via SVN at http://code.google.com/p/genomancer/ .  This should definitely
>> be
>> considered a beta release, there are plenty of features that aren't yet
>> implemented and I'm sure still some bugs in what is implemented.
>>
>> I'm hoping a stable version of this can eventually be set up close to or
>> integrated with the DAS1 registry.  For current testing I've deployed an
>> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
>> hardwired to proxy for the Sanger DAS1
>> registry<http://www.dasregistry.org/das1/sources>.
>>
>> Some example DAS2 queries and the DAS1 queries they proxy for:
>>
>> All DAS1 registry sources:
>> http://www.dasregistry.org/das1/sources
>> All DAS1 registry sources --> DAS1+2 sources
>> http://www.genomancer.org/das2/das1_proxy/sources
>>
>> DAS1 filtered sources
>> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
>> DAS1 filtered sources --> DAS1+2 filtered sources
>>
>> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>>
>> Ensembl DAS1 entry points
>> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>> Ensembl DAS1 entry points --> DAS2 segments
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>>
>> Uniprot DAS1 types
>> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>> Uniprot DAS1 types --> DAS2 types:
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>>
>> Uniprot DAS1 features (from UniProt DAS home page example)
>> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>> UniProt DAS1 features --> DAS2 features
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>>
>> Ensembl DAS1 features (from Ensembl DAS home page example)
>>
>> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
>> Ensembl DAS1 features --> DAS2 features
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>>
>> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
>> request (copied from IGB testing):
>>
>> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>>
>>
>> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>>   DAS1 sequence --> DAS2 segments
>>   DAS1 dsn --> DAS2 sources
>>   DAS1 stylesheet --> DAS2 stylesheet
>> I'll post a summary of plans for these queries and other features soon,
>> but
>> I wanted to at least send out this announcement so people who are
>> interested
>> can check out the examples.  Please let me know what you think.
>>
>>   Gregg
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>


From gregghelt at gmail.com  Wed Oct 29 06:52:07 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 03:52:07 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
Message-ID: <50158cb00810290352j1e33877bl623593fb84c17dfb@mail.gmail.com>

If anyone wants to test the DAS1 --> DAS2 transformational proxy with a
DAS/2 client, you can try it with the Integrated Genome Browser
(IGB)<http://www.affymetrix.com/partners_programs/programs/developer/tools/download_igb.affx>by
adding this line to your igb_prefs.xml file (usually located in your
home
directory):

<das2_server name="Trellis/Ivy DAS1 proxy" url="
http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types"
/>

Note that this server will show up in the "Data Access" tab for the current
genome and the "Pick Genome" button for genome selection along with other
DAS/2 servers, instead of in the "Access DAS1 Servers" menu item.

There are a few caveats.

IGB assumes that a DAS2 server provides "features", "segments", and "types"
capabilities for all the sources/versions it serves up.  But there are lots
of DAS servers in the registry that don't have a straightforward way for the
proxy to transform and provide all three capabilities.  To try and minimize
the number of sources IGB will have trouble with, the sources query above
includes filters to restrict the response to a (transformed) subset of the
sources listed in the registry that are likely to meet this requirement.
But there's currently no way to filter for exactly what is wanted (multiple
"capability" filters are OR'd together, not ANDed), so be warned that there
may still be some sources in the response that IGB can't deal with.

The other major caveat is that in order to compare annotations transformed
via the DAS1 proxy server alongside annotations from other DAS/2 servers,
IGB needs to be able to tell that they are using the same coordinate system
(genome assembly).  Currently the DAS1 registry and DAS/2 use different
identifiers for the same genome assembly.  Hopefully they can start using
the same identifiers soon, so I didn't really want to add a short-term (and
brittle) complete id mapping strategy in the proxy.  Until DAS1 and DAS/2
use the same coordinate identifiers the mapping at least for IGB can be done
in IGB, but to do this for the main Affymetrix IGB web start deployment
requires modification on the NetAffx Affymetrix web site (Steve, forgot to
talk to you about this yesterday -- I'll send you details).  So to test for
the next day or two I've done a single hardwired coordinates ID mapping in
the proxy for the latest human genome assembly (NCBIv36).  If you stick to
this genome in IGB you should be able to overlay data from the Trellis/Ivy
DAS1 proxy and other DAS2 servers.

Also keep in mind that none of the performance optimizations that the
Affymetrix Genometry DAS/2 server uses are implemented yet in the
Trellis/Ivy proxy.  So it's best to try out the proxy on small regions of
the genome.

Please let me know if you try this out how it works, any bugs you find, etc.

       Gregg

On Tue, Oct 28, 2008 at 11:02 AM, Gregg Helt <gregghelt at gmail.com> wrote:

> I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
> framework, and Ivy is the DAS1 proxy plugin.  The source code is available
> via SVN at http://code.google.com/p/genomancer/ .  This should definitely
> be considered a beta release, there are plenty of features that aren't yet
> implemented and I'm sure still some bugs in what is implemented.
>
> I'm hoping a stable version of this can eventually be set up close to or
> integrated with the DAS1 registry.  For current testing I've deployed an
> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
> hardwired to proxy for the Sanger DAS1 registry<http://www.dasregistry.org/das1/sources>.
> Some example DAS2 queries and the DAS1 queries they proxy for:
>
> All DAS1 registry sources:
> http://www.dasregistry.org/das1/sources
> All DAS1 registry sources --> DAS1+2 sources
> http://www.genomancer.org/das2/das1_proxy/sources
>
> DAS1 filtered sources
> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
> DAS1 filtered sources --> DAS1+2 filtered sources
>
> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>
> Ensembl DAS1 entry points
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
> Ensembl DAS1 entry points --> DAS2 segments
>
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>
> Uniprot DAS1 types
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
> Uniprot DAS1 types --> DAS2 types:
>
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>
> Uniprot DAS1 features (from UniProt DAS home page example)
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
> UniProt DAS1 features --> DAS2 features
>
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>
> Ensembl DAS1 features (from Ensembl DAS home page example)
>
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
> Ensembl DAS1 features --> DAS2 features
>
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>
> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
> request (copied from IGB testing):
>
> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>
>
> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>     DAS1 sequence --> DAS2 segments
>     DAS1 dsn --> DAS2 sources
>     DAS1 stylesheet --> DAS2 stylesheet
> I'll post a summary of plans for these queries and other features soon, but
> I wanted to at least send out this announcement so people who are interested
> can check out the examples.  Please let me know what you think.
>
>     Gregg
>
>
>
>

From gregghelt at gmail.com  Wed Oct 29 13:44:08 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 10:44:08 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <49087FF9.5080704@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
Message-ID: <50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>

Using the DAS/2.0 specification, this idea of "annotations of annotations"
is easy to do.  That's because every feature in DAS/2.0 has a unique URI and
is therefore addressable by _any_ other system that uses URIs -- including
another DAS/2.0 server:

<FEATURE uri="http://somewhere.else/feat123" ... >
     <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue XYZ"
/>
</FEATURE>

Or if you prefer allowing your meta-annotation to have it's own URI:

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

Used in this way DAS/2.0 becomes very RDF-like..

This is not just a happy accident but the result of a central tenet of DAS/2
-- addressability of all important DAS/2 entities outside the local system
via URIs.  The DAS/2 writeback spec is built on top of the DAS/2 retrieval
spec, so if you're fully implementing the writeback spec you should be able
to use this ability to do meta-annotations.

      Gregg

P.S. It's great to see development starting up again on DAS writeback!

On Wed, Oct 29, 2008 at 8:23 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>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
>

From gregghelt at gmail.com  Wed Oct 29 13:57:09 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 10:57:09 -0700
Subject: [DAS2] Crossposting to DAS and DAS/2 mailing lists
Message-ID: <50158cb00810291057t27feb2dm92d51797d8fab030@mail.gmail.com>

Hi everyone, just a reminder that we're in a transition period with folding
the DAS/2 mailing list back into the DAS list.  But it hasn't happened yet.
So please for now crosspost to both lists any posts that are of interest to
both.

     thanks,
     Gregg

From andy.jenkinson at ebi.ac.uk  Wed Oct 29 15:04:39 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 29 Oct 2008 19:04:39 +0000
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
Message-ID: <4908B3C7.5020002@ebi.ac.uk>

The difference between an ID and a URI is not so great, any ID can be a 
URI if we refer to the URN definition. But whether this URI should be 
resolvable (that is, a URL) is a big question. Whilst it is certainly a 
nice thing to be able to do, I'm not convinced of the practicality given 
the relationship between simplicity and adoption of technologies like DAS.

Ignoring the difficulty in making something actually resolvable (which 
can potentially be accomplished for features by just having 
"http://server/das/source/features?feature_id=foo") there is more 
pressure than ever on keeping verbosity low, and I'm not sure if this 
can be accomplished as things are right now when you have different URI 
prefixes in the same document. Gregg, perhaps you can elaborate?

I know you also advocate alternative content negotiation to solve this 
issue - do your alternative formats contain these URIs or do they strip 
them?

Gregg Helt wrote:
> Using the DAS/2.0 specification, this idea of "annotations of 
> annotations" is easy to do.  That's because every feature in DAS/2.0 has 
> a unique URI and is therefore addressable by _any_ other system that 
> uses URIs -- including another DAS/2.0 server:
> 
> <FEATURE uri="http://somewhere.else/feat123" ... >
>      <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue 
> XYZ" />
> </FEATURE>
> 
> Or if you prefer allowing your meta-annotation to have it's own URI:
> 
> <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>
> 
> Used in this way DAS/2.0 becomes very RDF-like..
> 
> This is not just a happy accident but the result of a central tenet of 
> DAS/2 -- addressability of all important DAS/2 entities outside the 
> local system via URIs.  The DAS/2 writeback spec is built on top of the 
> DAS/2 retrieval spec, so if you're fully implementing the writeback spec 
> you should be able to use this ability to do meta-annotations.
> 
>       Gregg
> 
> P.S. It's great to see development starting up again on DAS writeback!
> 
> On Wed, Oct 29, 2008 at 8:23 AM, Andy Jenkinson 
> <andy.jenkinson at ebi.ac.uk <mailto:andy.jenkinson at ebi.ac.uk>> 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
>     <mailto:andy.jenkinson at ebi.ac.uk>>
>     Organisation: European Bioinformatics Institute
>     To: Gustavo Salazar <gustavo at nbn.ac.za <mailto:gustavo at nbn.ac.za>>
>     References: <49058C89.7050301 at nbn.ac.za
>     <mailto: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 <mailto:DAS at lists.open-bio.org>
>         http://lists.open-bio.org/mailman/listinfo/das
> 
> 
>     _______________________________________________
>     DAS mailing list
>     DAS at lists.open-bio.org <mailto:DAS at lists.open-bio.org>
>     http://lists.open-bio.org/mailman/listinfo/das
> 
> 

From gregghelt at gmail.com  Wed Oct 29 16:20:47 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 13:20:47 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4908B3C7.5020002@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
	<4908B3C7.5020002@ebi.ac.uk>
Message-ID: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>

Sorry for being imprecise about URIs, what I meant to say was that every
feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
relative URIs but not absolute URIs, and referring to relative URIs is not
particularly useful outside their context.

Furthermore technically not all arbitrary ID strings can actually be
relative URIs either.  I thought this was mostly a theoretical issue until
my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
DAS1 data source I was testing,
http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns features
that derive their IDs from their genomic location, like
"21:26029715,26029814".  Which can't be any form of URI, because according
to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the appearance
of the colon before any forward slash means the "21" should be treated as
the URI scheme, but the scheme can't have a digit as the first character.
This isn't just a rare instance either -- I count at least sixteen data
sources like this (probably more) on ProServer servers for the latest human
genome assembly alone.  On a side note, I'm not sure if these IDs are legal
DAS1.53 feature IDs either, since many of them will not be unique within
their DAS server, and depeding on how you interpret the 1.53 spec the colon
may not be a legal ID character.

The Trellis/Ivy proxy now deals with these cases, but checking each ID to
see if it's a legal URI, and figuring out what to do if it's not, is
definitely adding some performance overhead to the proxy.

This also points to the need for better validation of server responses,
preferably as enhancements to the validation that the DAS1 registry already
does.  I doubt if the current DAS2 validator would catch these kinds of
things either.

I'll chime in with my opinion on the other issues you raise in another
email...

     Gregg

On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk>wrote:

> The difference between an ID and a URI is not so great, any ID can be a URI
> if we refer to the URN definition.

From gregghelt at gmail.com  Wed Oct 29 17:14:46 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 14:14:46 -0700
Subject: [DAS2] Links to old DAS/2 grant and final progress report
Message-ID: <50158cb00810291414u52198f35kd23774b8e538ba87@mail.gmail.com>

I've been reminded recently that when I say stuff like "well in the DAS/2
grant we proposed XYZ" few people can actually look at the old grant and see
what I'm talking about.  So I've posted a copy in a more permanent location:
http://biodas.s3.amazonaws.com/das2grant/DAS2+Grant+Proposal+Feb2003.doc .
I've also posted a copy of the final grant progress report:
http://biodas.s3.amazonaws.com/das2grant/DAS2+Grant+Final+Progress+Report+Aug2008.doc.
 If you do take a look at the grant, keep in mind it was written over
five
years ago.  Back then for example REST was still a relatively new concept,
and SOAP hype was peaking, so there's a fair amount of text dedicated to
explaining the RESTful approach we wanted to take and why we weren't just
using SOAP.  Since then some of the specifics have definitely changed, but I
think the general concepts hold up pretty well.  For instance the current
thread about meta-annotation had me looking back at the section on "Feature
References" and finding it's still relevant.

I've also added links on the BioDAS wiki DAS/2 pages to the grant and
progress report.

      Gregg

From andy.jenkinson at ebi.ac.uk  Wed Oct 29 18:15:08 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 29 Oct 2008 22:15:08 +0000
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	
	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
Message-ID: <4908E06C.3010800@ebi.ac.uk>

Gregg Helt wrote:
> 
> Sorry for being imprecise about URIs, what I meant to say was that every 
> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated 
> as relative URIs but not absolute URIs, and referring to relative URIs 
> is not particularly useful outside their context.

By relative URI do you mean URN (e.g. SO:12345)? As opposed to the HTML 
definition (e.g. index.html). URNs are still useful since they allow us 
to solve this issue of identifying things that are the same. A 
resolvable URI (i.e. a URL) is undoubtedly "better", but this is 
semantic web territory and I'm not convinced it is necessary for DAS. 
Certainly I think it would be too much a constraint to layer onto the 
existing spec in one increment. In fact even using URNs is not easy for 
everything - segment IDs cannot have colons.

> Furthermore technically not all arbitrary ID strings can actually be 
> relative URIs either.  I thought this was mostly a theoretical issue 
> until my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the 
> third DAS1 data source I was testing, 
> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns 
> features that derive their IDs from their genomic location, like 
> "21:26029715,26029814".  Which can't be any form of URI, because 
> according to the URI syntax spec <http://tools.ietf.org/html/rfc3986> 
> the appearance of the colon before any forward slash means the "21" 
> should be treated as the URI scheme, but the scheme can't have a digit 
> as the first character.  This isn't just a rare instance either -- I 
> count at least sixteen data sources like this (probably more) on 
> ProServer servers for the latest human genome assembly alone.

In this case, the ID is the least verbose but still unique-to-the-server 
ID possible, used because the annotation has no natural identifier (the 
source has per-base annotations). Believe me, there are far worse 
implementations - some servers don't even try to generate a unique ID 
for this kind of data. Leaving it blank is something that can be 
rejected in validation, but it's very difficult to verify it's actually 
unique...

There is nothing wrong with this particular example w.r.t the 1.53 spec, 
since the spec says nothing about IDs having to be URIs, it simply says 
they must uniquely identify the feature on the server. But you have hit 
upon one of the reasons _resolvable_ URIs (i.e. URLs) will be difficult 
to implement - annotations that have no natural identifier such as those 
in the batman_CD4 source. Plus, having a unique identifier for every 
base in a genome for every experiment it appears in is always going to 
be verbose.

> On a side 
> note, I'm not sure if these IDs are legal DAS1.53 feature IDs either, 
> since many of them will not be unique within their DAS server, and 
> depeding on how you interpret the 1.53 spec the colon may not be a legal 
> ID character.

I don't think there's a problem with the colon - this is an illegal 
character for reference IDs but not for feature IDs as far as I can see.

> The Trellis/Ivy proxy now deals with these cases, but checking each ID 
> to see if it's a legal URI, and figuring out what to do if it's not, is 
> definitely adding some performance overhead to the proxy.
> 
> This also points to the need for better validation of server responses, 
> preferably as enhancements to the validation that the DAS1 registry 
> already does.  I doubt if the current DAS2 validator would catch these 
> kinds of things either.

If you can give specific examples of things that could be targets for 
validation, I believe Jonathan will add them to his list so he can 
implement them... :)

From garret at globalmentor.com  Wed Oct 29 18:43:17 2008
From: garret at globalmentor.com (Garret Wilson)
Date: Wed, 29 Oct 2008 15:43:17 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
Message-ID: <4908E705.8050904@globalmentor.com>

Forgive me if I seem like I'm splitting hairs a bit here, but it may 
help to clear some of this up.

As RFC 3986 clarifies, there is no such thing as a "relative URI". All 
URIs are "absolute"---i.e. they start with a scheme.

There are, however, "URI references" which may be "URIs" (with a scheme) 
or "relative references". Relative references are a way to take 
advantage of the hierarchical nature of many URIs and store a shortened 
form of the URI in relation to some base URI---but they are not URIs.

The only way to tell if a URI reference is a URI or a relative reference 
is to check for ':', which indicates a URI scheme. Therefore, relative 
references may not have the character ':' within their first path 
segment. But that's not a problem---you can simply prefix the relative 
reference with "./"; thus, the ID "21:26029715,26029814" can easily be 
used as a relative reference in the form "./21:26029715,26029814". 
Again, this is not a URI---to create a URI, you have to resolve this 
relative reference against some base URI.

See RFC 3986 Sections 1.2.3. and 4.1.

Garret

Gregg Helt wrote:
> Sorry for being imprecise about URIs, what I meant to say was that every
> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
> relative URIs but not absolute URIs, and referring to relative URIs is not
> particularly useful outside their context.
>
> Furthermore technically not all arbitrary ID strings can actually be
> relative URIs either.  I thought this was mostly a theoretical issue until
> my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
> DAS1 data source I was testing,
> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns features
> that derive their IDs from their genomic location, like
> "21:26029715,26029814".  Which can't be any form of URI, because according
> to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the appearance
> of the colon before any forward slash means the "21" should be treated as
> the URI scheme, but the scheme can't have a digit as the first character.
> This isn't just a rare instance either -- I count at least sixteen data
> sources like this (probably more) on ProServer servers for the latest human
> genome assembly alone.  On a side note, I'm not sure if these IDs are legal
> DAS1.53 feature IDs either, since many of them will not be unique within
> their DAS server, and depeding on how you interpret the 1.53 spec the colon
> may not be a legal ID character.
>
> The Trellis/Ivy proxy now deals with these cases, but checking each ID to
> see if it's a legal URI, and figuring out what to do if it's not, is
> definitely adding some performance overhead to the proxy.
>
> This also points to the need for better validation of server responses,
> preferably as enhancements to the validation that the DAS1 registry already
> does.  I doubt if the current DAS2 validator would catch these kinds of
> things either.
>
> I'll chime in with my opinion on the other issues you raise in another
> email...
>
>      Gregg
>
> On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
> <andy.jenkinson at ebi.ac.uk>wrote:
>
>   
>> The difference between an ID and a URI is not so great, any ID can be a URI
>> if we refer to the URN definition.
>>     
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>   

From gregghelt at gmail.com  Wed Oct 29 19:39:49 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 16:39:49 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4908E705.8050904@globalmentor.com>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
	<4908E705.8050904@globalmentor.com>
Message-ID: <50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>

You're right, I'm still being sloppy about my terminology.

I've used the term "relative URI" as it's specified in the predecessor to
RFC 3986, RFC 2396 <http://www.ietf.org/rfc/rfc2396.txt> .  Apologies, many
of my conversations about the merits of URIs predate the release of RFC 3986
in 2005 -- old habits die hard.  And many specs still use the term "relative
URI".  But I'll try not say "relative URI" any more.  On the other hand, I
_really_ dislike the term "relative reference" because it's so generic, with
no indication of a relation to URIs in the term.  So if it's okay from now
on I'll use the term "relative URI reference" for what I've been calling
"relative URI" and what RFC 3986 calls "relative reference".

Argument via Google for using "relative URI reference":
Search for "relative uri reference" --  9,130 hits, all on first two pages
are relevant
Search for "relative reference" --   272,000 hits, _none_ on first two pages
are relevant, they're either using "relative reference" as a general
computer science term or specifically in relation to Excel.

So let me rephrase.  Every feature in DAS/2.0 has a unique URI.  In the
feature XML this is represented by the "uri" attribute of the FEATURE
element, which is a URI reference (URI or relative URI reference), and
optional xml:base attributes in the document.  DAS/2.0 uses the XML Base
specification <http://www.w3.org/TR/xmlbase/> to resolve relative URI
references via xml:base attributes and/or the URI the document is a
representation of.

So as you suggested, URI references are used in DAS/2.0 to optionally allow
shorthand in the XML for URIs.
Also as you suggested, the Trellis/Ivy DAS1-->DAS2 proxy uses "./" prefixing
to try and make relative URI references out of DAS1 IDs when the ID by
itself is neither a URI nor a relative URI reference.

       So many specs, so little time...
       Gregg

On Wed, Oct 29, 2008 at 3:43 PM, Garret Wilson <garret at globalmentor.com>wrote:

> Forgive me if I seem like I'm splitting hairs a bit here, but it may help
> to clear some of this up.
>
> As RFC 3986 clarifies, there is no such thing as a "relative URI". All URIs
> are "absolute"---i.e. they start with a scheme.
>
> There are, however, "URI references" which may be "URIs" (with a scheme) or
> "relative references". Relative references are a way to take advantage of
> the hierarchical nature of many URIs and store a shortened form of the URI
> in relation to some base URI---but they are not URIs.
>
> The only way to tell if a URI reference is a URI or a relative reference is
> to check for ':', which indicates a URI scheme. Therefore, relative
> references may not have the character ':' within their first path segment.
> But that's not a problem---you can simply prefix the relative reference with
> "./"; thus, the ID "21:26029715,26029814" can easily be used as a relative
> reference in the form "./21:26029715,26029814". Again, this is not a
> URI---to create a URI, you have to resolve this relative reference against
> some base URI.
>
> See RFC 3986 Sections 1.2.3. and 4.1.
>
> Garret
>
> Gregg Helt wrote:
>
>> Sorry for being imprecise about URIs, what I meant to say was that every
>> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated
>> as
>> relative URIs but not absolute URIs, and referring to relative URIs is not
>> particularly useful outside their context.
>>
>> Furthermore technically not all arbitrary ID strings can actually be
>> relative URIs either.  I thought this was mostly a theoretical issue until
>> my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
>> DAS1 data source I was testing,
>> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns
>> features
>> that derive their IDs from their genomic location, like
>> "21:26029715,26029814".  Which can't be any form of URI, because according
>> to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the
>> appearance
>> of the colon before any forward slash means the "21" should be treated as
>> the URI scheme, but the scheme can't have a digit as the first character.
>> This isn't just a rare instance either -- I count at least sixteen data
>> sources like this (probably more) on ProServer servers for the latest
>> human
>> genome assembly alone.  On a side note, I'm not sure if these IDs are
>> legal
>> DAS1.53 feature IDs either, since many of them will not be unique within
>> their DAS server, and depeding on how you interpret the 1.53 spec the
>> colon
>> may not be a legal ID character.
>>
>> The Trellis/Ivy proxy now deals with these cases, but checking each ID to
>> see if it's a legal URI, and figuring out what to do if it's not, is
>> definitely adding some performance overhead to the proxy.
>>
>> This also points to the need for better validation of server responses,
>> preferably as enhancements to the validation that the DAS1 registry
>> already
>> does.  I doubt if the current DAS2 validator would catch these kinds of
>> things either.
>>
>> I'll chime in with my opinion on the other issues you raise in another
>> email...
>>
>>     Gregg
>>
>> On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>
>>
>>> The difference between an ID and a URI is not so great, any ID can be a
>>> URI
>>> if we refer to the URN definition.
>>>
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>

From gregghelt at gmail.com  Wed Oct 29 20:29:08 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 17:29:08 -0700
Subject: [DAS2] DAS UML modeling
Message-ID: <50158cb00810291729w4ea8a8fbn755e23d4e2a1db7@mail.gmail.com>

I've committed my latest DAS UML modeling docs into the genomancer source
repository:
     http://genomancer.googlecode.com/svn/trunk/uml/Das.zuml
     http://genomancer.googlecode.com/svn/trunk/uml/Das.xmi

UML modeling of RESTful web services is not a well-defined area -- please
let me know if you have suggestions.  The diagrams in Das.zuml look good in
the Poseidon UML modeler.  Not sure what they'll look like in other apps,
UML diagram rendering standardization efforts still seem iffy.

I've also committed images of some of the diagrams.  Relevant to discussion
of DAS1 to DAS2 comparisons:

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS%20Feature%20Comparison.png

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS%20Feature%20Alignment%20Comparison%20UML.png
These diagrams compare models of DAS1 features, DAS2 features, and DAS1.53E
alignments side-by-side.  I've added some color-coding to highlight
differences that standard UML wouldn't show.  Model fields that are required
attributes/elements in DAS XML are highlighted in red.  References to
elements within the same document are highlighted in green.  References to
elements in other documents are highlighted in purple.

And here's images of the more complete DAS1 and DAS2 models, which have
served as a basis for the Trellis DAS/2 server framework, the Vine DAS/2
proxy plugin, and the Ivy DAS1 proxy plugin:

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS2%20Abstract%20UML.png

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS1%20Abstract%20UML.png

   Gregg

From gregghelt at gmail.com  Wed Oct 29 22:33:26 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 19:33:26 -0700
Subject: [DAS2] using ProServer as a DAS source for IGB
In-Reply-To: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
References: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
Message-ID: <50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>

You're not seeing DAS/2 in IGB because the use of DAS/2 has become an
integral part of IGB, to the point that it's no longer advertised as such.
This was partly motivated by feedback at Affymetrix (internally and from
customers) that DAS1, DAS/2, any mention of these things in IGB was just
confusing to users who didn't know what those were and didnt' really care
what protocol was being used, they just wanted to see the data.

So (unless you've tweaked some advanced prefs) when IGB first launches, goes
to a particular genome assembly, a particular chromosome, and pulls up the
chromosomal banding pattern and RefSeq annotations for that chromosome, all
that is happening via DAS/2.  The "Pick Genome" button that's used to switch
to a different genome assembly uses DAS/2.  The data access panel at the
bottom of IGB that allows you to select other annotation types to load is
using DAS/2.  The tricky bits of ID-to-genome-coordinate resolution that
happen behind the scenes if you load an Affymetrix gene or exon chp file
uses DAS/2.

Now there's a whole separate chunk of code in IGB that enables getting
annotations from DAS1 servers, which is accessed via the File-->"Access
DAS/1 Servers" menu item that you mention.  This is a much older code base,
and for some DAS1 servers it works, but for many others it doesn't.  For
your particular case I'm guessing that the IGB code is ignoring the
X-Das-Capabilities header and assuming that your server supports "types",
"features", and "entry_points" queries (or points to a MapMaster that
supports "entry_points" queries), and it's choking when it turns out the
server doesn't support either "types" or "entry_points".  This is definitely
a bug in IGB, and it didn't get fixed back when the IGB DAS1 client was
being developed because the DAS1 servers that most IGB users were accessing
at the time didn't trigger this bug.

Assuming the problem is with IGB's handling of DAS1 servers, there's several
possible solutions.

1) Configure your DAS server to support all three of the queries the IGB
DAS1 client needs: "types", "features", "entry_points".

2) Trellis/Ivy, the DAS1-->DAS2 proxy I've been developing, might work for
this situation.  Currently it probably won't, as the IGB DAS/2 client also
requires that the DAS/2 data sources support the DAS/2 "types" query.  But
this code base is evolving rapidly, and soon the proxy may be able to inject
type support for DAS1 servers that don't support "types" queries.  It
already does this kind of injection of the DAS/2 "segments" query for many
DAS1 sources in the Sanger DAS1 registry that don't list a
"das1:entry_points" capability.  One caveat to this approach is that
Trellis/Ivy supports the "sources" query but not the "dsn" query, and may
not ever since it looks like "dsn" may soon be deprecated.  Does ProServer
support the 1.53E "sources" query as an alternative to "dsn"?

3) Modify IGB so it can deal with DAS1 servers that don't support "types"
and "entry_points" queries.  But I'm reluctant to dive back into the old IGB
DAS1 code, and I doubt if anyone else wants to either.

4) Modify IGB so it can deal with DAS/2 servers that don't support "types"
and "segments" queries.  This is going to happen eventually, it's just a
question of timing.  Then Trellis/Ivy could be used as-is to proxy for the
DAS1 server and respons to IGB DAS/2 queries.

If it's straightforward to configure the DAS1 server to support "types" and
"entry_points" queries, then that's probably the quickest route.

One other caveat -- in order for IGB to overlay annotations from multiple
data sources, it needs to realize that they're using the same coordinate
system.  If coordinate system IDs don't match exactly, IGB uses a synonym
resolution strategy which usually relies on the synonyms doc at
http://netaffxdas.affymetrix.com/quickload_data/synonyms.txt .  If you can't
overlay annotations from multiple servers it's probably because their
coordinate IDs aren't listed as synonyms.  Let me and/or Steve Trutane know
(steve_chervitz at affymetrix.com) and he can add them in.  Hopefully increased
use of the DAS1 and DAS2 registries will lessen IGB's dependence on synonym
resolution.

      hope that helps,
      Gregg

On Mon, Oct 20, 2008 at 7:24 AM, Hotz, Hans-Rudolf
<hans-rudolf.hotz at fmi.ch>wrote:

> Hi
>
> Your e-mail was given to my by Andy Jenkinson one of the ProServer
> (http://www.sanger.ac.uk/Software/analysis/proserver/) developers at the
> EBI
> in Hinxton, UK).
>
> I am struggling to understand which DAS protocol is used in IGB. All the
> menu tabs are suggesting it is DAS/1 (eg File-> "Access DAS/1 Servers").
> But
> the release notes suggest is DAS/2. And if I try to load data from my
> ProServer I get:
>
>   Error parsing DAS Source
>   org.xml.sax.SAXParseException: Content is not allowed in prolog.
>
>
> Is there a way to use ProServer with IGB?
>
> Thank you very much for your help
>
> Hans
>
>
> Friedrich Miescher Institute
> for Biomedical Research
> Maulbeerstrasse 66
> 4058 Basel/Switzerland
>
>

From Steve_Chervitz at affymetrix.com  Wed Oct 29 22:46:19 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Wed, 29 Oct 2008 19:46:19 -0700
Subject: [DAS2] Minutes from 16 Oct 2008 DAS teleconference
Message-ID: <C52E6E0B.32FE5%Steve_Chervitz@affymetrix.com>

Notes from the biweekly DAS/2 teleconference, 16 Oct 2008

$Id: das2-teleconference-2008-10-16.txt,v 1.1 2008/10/30 02:42:50 sac Exp $

Teleconference Info:
   * Schedule:         Biweekly on Thursday
   * Time of Day:      9:00 AM PDT, 12:00 PM EST, 16:00 GMT
   * Dialin (US):      704-687-8984

Attendees: 
    Free agent: Gregg Helt
    Affymetrix: Steve Chervitz
    EBI: Andy Jenkinson
    Sanger: Jonathan Warren
    U North Carolina: Ann Loraine, Steven Blanchard, John Nicol
    U Utah: David Nix
    LBNL: Suzi Lewis

Note taker: Steve Chervitz

Action items are flagged with '[A]'.

The teleconference schedule and links to past minutes are
available from the Community Portal section of the biodas.org site:
http://www.biodas.org/wiki/BioDAS:Community_Portal#Teleconference

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit on the the discussion list.

========================================================
Agenda: 
* Das1/2 integration
* Security and auth
* Proposed spec changes

Ann: I volunteered to look into getting RCN funding - haven't done
anything on that.

Gregg: Suzy, Me and Ian (Holmes) will submit something in Feb. With
Suzy as the PI. Also, she mentioned that Gmod help desk would get
involved. 

Suzi: This will keep us to 3 institutions, better than 4 -- too
disconnected.

Gregg: combined Sanger, EBI, South Africa network submission
(December).

Andy: Still going ahead. Working on adding writeback.

[A] for Suzi: Decide if it be Ian or Suzi as PI. Can issue reciprocal
letters of collab.

[A] for Steve: Combine das and das2 lists. Can they be merged.
Check into best way to do this: bounce with message to repost, or
automatically forward anything sent to das2 to the das list
(better). Also: make steve admin on das list, add members from das2 to
das1

Gregg: Important to recover the early discussions

Lincoln (not on this call) is on paternity leave (10/11 girl)

Ann: Ad hoc meetings or regular?
Consensus: regular

Suzi: q for sanger/EBI - how many people would care about das spec?
Doesn't sound like all stakeholders are on the line.

Andy: Quite a few do, but not all can find time to participate. quite
busy. I will serve as their representative for these calls.

Topic: Authentication
===========================

David Nix: Security and auth. What's going on with that?
Summary: I work in core facility, get requests to process data,
private, to be hosted on das server, return to PIs, log into das
server and retrieve data. I hacked into genoviz das2 server a way to
do it, not built into spec, but is really needed. Want to compare
private tracks to public.

We have many diff groups with diff folders, each needs diff permission
settings (lab only, lab + collabs, organization only). Came up with a
custom solution on the das2 servlet rather than a standard http-based
authentication route.

One possible approach: Issuing a special types request suited for that
person. 

GH (Gregg): We only used http auth, worked for us, but is all or none access
to a das source. differentiating based on types w/in an

Steven (UNC): Looking into http authentication. have a test
running. can do arbitrary auth for certain types but not others. Can
force it on a query parameter.

GH: Tomcat realms etc. looking into this.

Steven: Can't to that. Need to create a servelet filter, can send back
a 401 on any server you want auth on.

Nix: Concern: for some labs, they want to keep the genome they're
working on to be private. Do you have to make a request for the track
before you're allowed to see it (e.g., dnase footprinting track)?

steven: challenge response, so server would leak track names. But you
can hide tracks from users if they're not authenticated. Comes down to
the implementation side, not the spec.

GH: running multiple servlets problems could be because of gregg's
implementation. Should be no problem for diff servlets running in same
tomcat. Genometry server was impl under assumption that it's data
model might be shared between diff servlets. Might need to be fixed.

Nix: I have >30 folders. Running so many diff servlet instances would
be insanity.

Concerned about management of permission files. Want someone to
administer via webpage, not a sysadmin. Want to enable lab managers to
add users, change permissions w/o having to send requests to
core lab developers/sysadmins.

Steven: Policy file is java policy file (Using jazz for security
framework). Have flexibility of where policy info is stored. Could be
managed via database.

UK folks security needs?
Intend to use openId system to do authentication. Permissions would be
downstream from authentication. Permissions attributed to different
users haven't been addressed yet. Two separate issues.

UK: Auth is performed by delegate servers.
works across the whole system, rather than having server-specific

Das registry uses it now.

GH: Security/auth is orthogonal to the spec. should be kept separate.

UK: Expectations should be indicated.

Steven: Spec should say that it supports protocol somehow, but not go
into implementation-specific things.
E.g., Do you need to authentical before you can see anything

UK: Good thing about OpenID

Steven: Worry: most client libraries and langs do not support it, whereas
http
auth is more widely supported.

Suzi: There won't be lots of people writing clients, just lots of users.

GH: Concern about putting anything about seecurity and auth into the
spec, adds more to debate about. We've got 3-4 different options
already. Would like to keep it out of the spec.

Suzi: The need is there given interest addressed here. We should say
something about it in the spec. Need to pick one.

UK: Anyone reviewing this proposal will ask about it.

[A] for someone: Need a summation of the pros and cons, bite the bullet and
choose
a path. Need a person to review descriptions and make a decision.

Ann: Would be good to have a statement of pros and cons of different
positions. But yes, a final decision should be there.

Suzi: Someone else could review/summarize a different person's
suggestion.

UK: Agree.

Suzi: I will be reviewer.

[A] Gregg will forward our off-list discussions to the list to get input
from others.

Nix: Don't care so much about impl. Really need a way to formulate a
custom response to an individual. Would be great solve via best
practices. 

SC: Security/auth will be very important with the growing interest in
personalized medicine. Great to get this nailed in the spec.


Topic: Das1-2 spec merging
===========================

GH: Has everyone had a chance to review Andy's writeup?

Suzi: Anyone gone through point by point to see where diffs lie?
GH: Yes. While at Sanger. Meeting about making changes to das 1.5
spec. Talked about hybridizing them. Have side-by-side UML models.

[A] Gregg will send out side-by-side UML models (pictures and/or model
files).

GH: Re integration: Andy said biggest issue for sanger/ebi/biosapiens
is backward compatibility (lack thereof) for das2

Suzi: what pieces in das2 spec are not backwards compatibile? Which
features that are fundamentally different?

GH: working on making das1-> das2 proxy. Very aware of the diffs:
Summary: (see das plan from Jonathan and Andy for change needed to
das1.5 spec)
1) the notion that everything has unique URI in das2  (das1 things
   have
2) hierarchical features
3) Location spec of features (0,1, many) covers gene das and das1
   alignments. We condensed down the alignments into annotations that
   have potentially multiple locations, Bridging these can be
   challenging.
4) Alternative content types. Negotiated between client-server. Enable
   returning back much more efficient format than xml.

Suzi: could that sit on top of something than can/can't negotiate?
GH: Maybe. But gets to backward compatibility. Changing optional <->
required breaks compatibility.  E.g., saying you can ignore anything
you don't understand.

Jonathan: Non lossy conversion? Important for getting people on
board if it is lossy.

GH: Forward from das1->das2 is possible. Das2 allows injection of
arbitrary xml (which can be das1 xml). Not possible in reverse
direction. Looking into proper translation into das2 elements and also
preserve das1 xml.

Suzi: Motivations are still the same. Revisiting the specification, we
all have same issues. Ability to deal with hierarchical data. Seems
very important. Should be translatable non-lossy.

GH: Not translatable in a std fashion. It's a standard you'll have to
force on top of das1 spec to achieve this.

Suzi: Motivations for changing where we are, are the problems we're
trying to solve the same (for 1.5 or 2)?

GH: Main dichotomy is mainly proteins vs genomes vs genes. Stuff built
in das2 may not be appropriate for proteins (slices of annotations on
a range -- you want all of them). Similarly regarding types, might want a
better
breakdown of things without sending all proteins.

Andy: Not many diffs in what we're trying to achieve. Need to
determine whether we want to change a server to support a
protocol. Much more difficult. Once we solve the gaps in das1. Need a
way upgrade without a complex process, w/o using das1 proxy.

Suzi: not a viable long-term solution.

GH: Hard to make tweaks to a spec that uses XML the way that Das1
uses it w/o breaking ba
gene das says you don't need start/stop. Takes two required args and
makes them optional. E.g., my client assumes there's a start and stop
so will break.

Andy: Will still process the request...

GH: Disagree for gene das. Send a query asking for all feats, and you
get something back w/o start-stop.

Andy: Far fewer clients than you have servers. Changing servers is
harder than clients.  Different degrees of "breaking".

Suzi: you mean implementations, right? Might be more instances of
clients running, but more different types of servers?

Andy: Fewer client installations than there are servers, since most
clients are web based.
Suzi: I was counting all web based ones as well.
UK: Using Java web start, clients can be updated automatically.

Suzi: How move forwared.

GH: Implementing das1 proxy, to help people (and self) be aware of
the differences. Posted code to Google code proj. Project=Genomancer
(necromancer for genes!)

[A] gregg - write proposed changes to sources document more formally.
Sanger/EBI are working on 1.6 which includes sources. Rev das2 to have
more updated source command as well.

Jonathan, Andy: [Lots of chop on the phone line] Validation for
registry using XSD. Also ddding requested features to the das
spec. Need to see where it's being used.

Suzi: We want to have one single spec.

UK: Right.

GH: RelaxNG for the sources command?

UK: Just started. haven't used it before.

Someone: Why using XSD?

Andy: Need better validation. Newer commands using XSD, since no one
is using DTDs.

Suzi: Why not consider RelaxNG. I used to be a XSD person, but have
become a fan of RNG.

UK: We can look at it.

GH: Andrew (Dalke) convinced me to use RNG and I've been pleased. XSD
is difficult to read/work with.

UK: It's not too late to change it.

Suzi: We want one spec. Treat it like a football. One person holds it
at a time. pass it back and forth. Multiple editors can be a
problem. Need to be sympathetic with people who come in with
requirements.

GH: For das2 grant, I appointed Andrew as spec czar. Only he could
make changes to the formal schema, other can change HTML docs. Avoided
conflicts in the schema.

UK: [lots of chop on line]. Doing a small remediation to the 1.5 spec,
then we'll have a spec that can incorporate more of the das2
requirements.

[A] UK folks: Continued Das integration work.

Suzi: One spec czar + multiple html editors.
GH: I gave Andrew veto power, but if he abuses it, we'd depose him!
GH: Needs to be called something different. Das3?
Suzi: no! 
UK: Just DAS?
Suzi: Yes, "Das", with releases.

[A] Anyone interested in contributing: look at links from Andy/Jonathan on
how das1 is changing.

Ann: Das2 spec for making changes to genometry server. How to edit
this doc so changes can be rolled back in?  HTML.

GH: Steve?

SC: Yes, I can work on wikifying the existing DAS HTML spec on the
biodas.org wiki.

GH: Like the idea of wikifying them. Next week?

Ann: Stable HTML version + separate live document

[A] Steve wikify the HTML docs.

John (UNCC): Genomancer code is up to date?

GH: Yes, but not usable yet. Das2 -> das2 proxy ok, but needs
docs. But das1-> das2 is not functional yet.

SC: What's purpose of das2 to das2?

GH: das2->das2: can do lots of interesting things: Inject alt content
format. Serve json from a single das2 point. Lots of stuff...

[A] All: Teleconf in two weeks, same time, but need better phone line!



------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.

From aloraine at gmail.com  Thu Oct 30 00:07:04 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Thu, 30 Oct 2008 00:07:04 -0400
Subject: [DAS2] using ProServer as a DAS source for IGB
In-Reply-To: <50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>
References: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
	<50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>
Message-ID: <83722dde0810292107y41bdd9c8s4893d44fa7df62fe@mail.gmail.com>

I think Dr. Hotz is describing a difficulty many people have
experienced when working with IGB -- the various methods for loading
data into the browser are very confusing.

Here at Charlotte we're working on a new interface that aims to solve
this problem and make IGB much easier to operate.

One goal for the new data-loading interface is to let the user perform
essentially the same operations for loading data regardless of whether
the data are flowing from a DAS1 site, a DAS2 site, or from files on
the user's file system. (In the latter case, the user might need to
provide a simple file describing how the genome is put together, e.g.,
like the mod_chromInfo.txt from the old QuickLoad scheme.)

I'm working on a design document and will circulate it to anyone who
is interested in commenting or offering suggestions. Dr. Holtz please
let me know if this something you might like to do!

Sincerely,

Ann Loraine


On Wed, Oct 29, 2008 at 10:33 PM, Gregg Helt <gregghelt at gmail.com> wrote:
> You're not seeing DAS/2 in IGB because the use of DAS/2 has become an
> integral part of IGB, to the point that it's no longer advertised as such.
> This was partly motivated by feedback at Affymetrix (internally and from
> customers) that DAS1, DAS/2, any mention of these things in IGB was just
> confusing to users who didn't know what those were and didnt' really care
> what protocol was being used, they just wanted to see the data.
>
> So (unless you've tweaked some advanced prefs) when IGB first launches, goes
> to a particular genome assembly, a particular chromosome, and pulls up the
> chromosomal banding pattern and RefSeq annotations for that chromosome, all
> that is happening via DAS/2.  The "Pick Genome" button that's used to switch
> to a different genome assembly uses DAS/2.  The data access panel at the
> bottom of IGB that allows you to select other annotation types to load is
> using DAS/2.  The tricky bits of ID-to-genome-coordinate resolution that
> happen behind the scenes if you load an Affymetrix gene or exon chp file
> uses DAS/2.
>
> Now there's a whole separate chunk of code in IGB that enables getting
> annotations from DAS1 servers, which is accessed via the File-->"Access
> DAS/1 Servers" menu item that you mention.  This is a much older code base,
> and for some DAS1 servers it works, but for many others it doesn't.  For
> your particular case I'm guessing that the IGB code is ignoring the
> X-Das-Capabilities header and assuming that your server supports "types",
> "features", and "entry_points" queries (or points to a MapMaster that
> supports "entry_points" queries), and it's choking when it turns out the
> server doesn't support either "types" or "entry_points".  This is definitely
> a bug in IGB, and it didn't get fixed back when the IGB DAS1 client was
> being developed because the DAS1 servers that most IGB users were accessing
> at the time didn't trigger this bug.
>
> Assuming the problem is with IGB's handling of DAS1 servers, there's several
> possible solutions.
>
> 1) Configure your DAS server to support all three of the queries the IGB
> DAS1 client needs: "types", "features", "entry_points".
>
> 2) Trellis/Ivy, the DAS1-->DAS2 proxy I've been developing, might work for
> this situation.  Currently it probably won't, as the IGB DAS/2 client also
> requires that the DAS/2 data sources support the DAS/2 "types" query.  But
> this code base is evolving rapidly, and soon the proxy may be able to inject
> type support for DAS1 servers that don't support "types" queries.  It
> already does this kind of injection of the DAS/2 "segments" query for many
> DAS1 sources in the Sanger DAS1 registry that don't list a
> "das1:entry_points" capability.  One caveat to this approach is that
> Trellis/Ivy supports the "sources" query but not the "dsn" query, and may
> not ever since it looks like "dsn" may soon be deprecated.  Does ProServer
> support the 1.53E "sources" query as an alternative to "dsn"?
>
> 3) Modify IGB so it can deal with DAS1 servers that don't support "types"
> and "entry_points" queries.  But I'm reluctant to dive back into the old IGB
> DAS1 code, and I doubt if anyone else wants to either.
>
> 4) Modify IGB so it can deal with DAS/2 servers that don't support "types"
> and "segments" queries.  This is going to happen eventually, it's just a
> question of timing.  Then Trellis/Ivy could be used as-is to proxy for the
> DAS1 server and respons to IGB DAS/2 queries.
>
> If it's straightforward to configure the DAS1 server to support "types" and
> "entry_points" queries, then that's probably the quickest route.
>
> One other caveat -- in order for IGB to overlay annotations from multiple
> data sources, it needs to realize that they're using the same coordinate
> system.  If coordinate system IDs don't match exactly, IGB uses a synonym
> resolution strategy which usually relies on the synonyms doc at
> http://netaffxdas.affymetrix.com/quickload_data/synonyms.txt .  If you can't
> overlay annotations from multiple servers it's probably because their
> coordinate IDs aren't listed as synonyms.  Let me and/or Steve Trutane know
> (steve_chervitz at affymetrix.com) and he can add them in.  Hopefully increased
> use of the DAS1 and DAS2 registries will lessen IGB's dependence on synonym
> resolution.
>
>      hope that helps,
>      Gregg
>
> On Mon, Oct 20, 2008 at 7:24 AM, Hotz, Hans-Rudolf
> <hans-rudolf.hotz at fmi.ch>wrote:
>
>> Hi
>>
>> Your e-mail was given to my by Andy Jenkinson one of the ProServer
>> (http://www.sanger.ac.uk/Software/analysis/proserver/) developers at the
>> EBI
>> in Hinxton, UK).
>>
>> I am struggling to understand which DAS protocol is used in IGB. All the
>> menu tabs are suggesting it is DAS/1 (eg File-> "Access DAS/1 Servers").
>> But
>> the release notes suggest is DAS/2. And if I try to load data from my
>> ProServer I get:
>>
>>   Error parsing DAS Source
>>   org.xml.sax.SAXParseException: Content is not allowed in prolog.
>>
>>
>> Is there a way to use ProServer with IGB?
>>
>> Thank you very much for your help
>>
>> Hans
>>
>>
>> Friedrich Miescher Institute
>> for Biomedical Research
>> Maulbeerstrasse 66
>> 4058 Basel/Switzerland
>>
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>

From gregghelt at gmail.com  Thu Oct 30 02:06:01 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 23:06:01 -0700
Subject: [DAS2] DAS Teleconference Thursday October 30th, 9AM PST
Message-ID: <50158cb00810292306i10450b3aq3b60e16122530fdf@mail.gmail.com>

Just a reminder to everyone that there's a DAS teleconference
tomorrow/today, Thursday October 30th, at 9AM PST (4 PM GMT).  In an effort
to confuse people we're trying yet another teleconference number:

US and Canada Dial-in:  1-800-391-1709
International Dial-in:  001-310-539-2229
Conference Bridge#:     747999

Topics:
    Review progress on action items from last week (see Steve's post of
minutes, which lists action items)
    I'd like to give an overview of the Trellis/Ivy DAS1-->DAS2 proxy, and
future plans for it
    ???


Gregg

From gregghelt at gmail.com  Thu Oct 30 02:30:42 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 23:30:42 -0700
Subject: [DAS2] Fwd: Using HTTP authentication for DAS/2
In-Reply-To: <83722dde0809260602k611fd1a0u8df00b718d819ed4@mail.gmail.com>
References: <457119e10809241559x417e5c1br15193911bcc45ac@mail.gmail.com>
	<916324E1C885C54989449104CB7225B6028EA5EF@EMAIL1.hci.utah.edu>
	<457119e10809250921j18184230g1a0d0e427877d5ef@mail.gmail.com>
	<83722dde0809260601k196062c6pec0ebd69e84728e2@mail.gmail.com>
	<83722dde0809260602k611fd1a0u8df00b718d819ed4@mail.gmail.com>
Message-ID: <50158cb00810292330q727d8699teaa6b3f1ac998c36@mail.gmail.com>

More background on recent discussions regarding DAS security and
authorization.

---------- Forwarded message ----------
From: Ann Loraine <aloraine at gmail.com>
Date: Fri, Sep 26, 2008 at 9:01 AM
Subject: Re: Using HTTP authentication for DAS/2
To: Steven Blanchard <sgblanch at gmail.com>
Cc: Tonya DiSera <tony.disera at hci.utah.edu>, David Nix
<david.nix at hci.utah.edu>, nicol.john at gmail.com, Brett Milash
<brett.milash at hci.utah.edu>, Robb Cundick <robb.cundick at hci.utah.edu>


I'm not sure if I understand the various technical aspects here - my
apologies! I'm also getting up to speed on this particular issue :-)

Do I understand correctly?

If a lab were to set up its own private DAS site to serve unpublished
or preliminary lab data, it sounds as though they could right this
moment use the technique Steven demo'd in his first email. But if they
also wanted to serve free and open data (for example, as a companion
to a published article) then they would need to set up and run an
entirely new instance of the DAS servlet.

One of our big goals in the Loraine group is to deliver a DAS server
to TAIR and possibly iPlant, which would ultimately serve free and
open data. But I would also want for individual labs to be able to set
up their own private resources. In those cases, users would want to
access the public data (e.g., the foundation TAIR8 annotations)  and
view these foundation annotations alongside their unpublished data
sets, e.g, Arabidopsis tiling array data.

TAIR = www.arabidopsis.org

-Ann

On Thu, Sep 25, 2008 at 12:21 PM, Steven Blanchard <sgblanch at gmail.com>
wrote:
> I have not gotten as far as thinking about your second point
> (authorization).  I am still working on just authentication.  My
> official statement is that HTTP authentication will support mixed
> authenticated/unauthenticated access just fine.
>
> That being said, my previous email glossed over the separation of the
> DAS/2 specification and our DAS/2 server implementation.  If we use
> HTTP authentication, we do not have to specify any authorization model
> in the DAS/2 specification.  If we add our own authentication into the
> DAS/2 specification we will also need to add authorization to the
> specification.  I like the ability to leave the authorization details
> to server implementers as one authorization model may not work for
> everyone.  On the client side, as long as a it supports HTTP
> authentication the client will 'do the right thing' when a server
> requires authenticated access.
>
> My other emails cover implementation details related to supporting
> HTTP authentication, so I will not rehash them here.  Now all we need
> to do is decide on whether to add the current
> authentication/authorization model to the specification or to switch
> to HTTP authentication and decide on an implementation strategy.
>
> Thanks,
> ~Steven
>
>
> 2008/9/25 Tonya DiSera <tony.disera at hci.utah.edu>:
>> Hi Team -
>>
>> I'm just getting familiar with this project, so I apologize if I am
>> covering issues already thought through.
>>
>> David, Brett, and I recently devised a security model for our GNomEx
>> application that allows for both public and private access to
>> experimental data. At first glance, DAS would seem to benefit from a
>> similar security model architected at two levels:
>>
>> 1)  A basic access layer, permitting either public access (guest access,
>> no authentication) or private (login) access.  The trick here is that we
>> want the servlet to be accessed both in an authenticated mode and a
>> non-authenticated mode.  I've devised an implementation that relies on a
>> "gate keeper" servlet that I can expand upon if we find this to be an
>> important consideration.  Steve, it sounds like you have a good handle
>> on the HTTP authentication model.  Is there a way we can rely on this
>> standard implementation, permitting both authenticated and
>> non-authenticated access to the servlet?
>>
>> 2)  A data access layer governed by user/group permissions assigned to
>> specific data sources.  This layer would be implemented by servlet
>> application code that would filter data sources based on the user/group
>> permissions assigned to each data source and the scope of visibility set
>> on the data source.  For example, some data sources would be marked as
>> "public" by the submitter and would therefore be visible to all users.
>> Data sources marked as "private" would be visible to only those users
>> belonging to groups permitted to view this data.
>>
>> Thanks,
>>  Tony Di Sera
>>
>> -----Original Message-----
>> From: Steven Blanchard [mailto:sgblanch at gmail.com]
>> Sent: Wednesday, September 24, 2008 5:00 PM
>> To: David Nix
>> Cc: Ann Loraine; nicol.john at gmail.com; Brett Milash; Tonya DiSera; Robb
>> Cundick
>> Subject: Re: Using HTTP authentication for DAS/2
>>
>> When I was testing, I had only password protected one entire genome of
>> the two that were on the server.  Password protecting only particular
>> annotations would be a bit more complex.  Instead of relying on
>> path-based controls, I think that the DAS/2 servlet could generate the
>> 401 Authorization Required internally and force clients to
>> authenticate when necessary.  If the DAS/2 servlet can generate the
>> 401--which I see no technical reason it can not--it would allow a web
>> admin page to modify permissions on the fly instead of having the
>> systems administrator mucking about with the web.xml.  Again, I will
>> need to test to make sure that this is the case before we decide to
>> commit to this path.
>>
>> ~Steven
>>
>> 2008/9/24 David Nix <david.nix at hci.utah.edu>:
>>> Yes, this is slowly coming back my apologies.
>>>
>>> I did look into using the http authentication the problem is the
>>> granularity.  I believe they provide all or nothing access to the
>> servlet.
>>> Thus each lab would have to have their own servlet instance with
>> pointers to
>>> their data. (We've got a growing list of 20 labs with private and
>> public
>>> data.) Most servlet containers explicitly avoid multiple instances and
>> work
>>> with a shared instance.  I looked into running multiple instances and
>> or
>>> multiple tomcat servers and it got rather ugly.
>>>
>>> Is there a way of allowing everyone to access the servlet but passing
>> to it
>>> the credentials from the http authentication?  That would be a good
>>> solution.
>>>
>>> -cheers, D
>>>
>>>
>>> On 9/24/08 2:52 PM, "Steven Blanchard" <sgblanch at gmail.com> wrote:
>>>
>>>> Apologies this rambles a little:  I wanted to get it out while
>>>> everything was still fresh in my mind.
>>>>
>>>> The three types of HTTP authentication I know about are Basic,
>> Digest,
>>>> and Negotiate.  Basic and Digest authentication are the most common.
>>>> Basic authentication sends usernames and passwords across the wire in
>>>> clear text.  Digest authentication uses an MD5 digest of the password
>>>> instead of the actual password itself but can not be used with some
>>>> back-end authentication databases.  Negotiate authentication is
>>>> designed to enable Kerberos and other similar authentication schemes,
>>>> but is not well supported.  The advantage I see to using HTTP
>>>> authentication is that a server administrator can leverage any
>>>> authentication mechanism supported by the servlet server.
>>>>
>>>> As a test, I used basic authentication to  password protect a genome
>>>> on our DAS/2 server.  I chose to use HTTP Basic authentication backed
>>>> by our LDAP directory.  The configuration I created allowed anyone in
>>>> the 'admin' LDAP group to access the password-protected genome.  Note
>>>> that this configuration does transmit passwords in the clear.
>>>>
>>>> When I accessed the protected genome using IGB, it created a login
>> box
>>>> asking for the user to authenticate to the server which worked as
>>>> expected.  The dialog box was created by Java itself: I did not
>> change
>>>> a single line of code in IGB or the DAS/2 servlet.
>>>>
>>>> If we were to adopt HTTP authentication as the offical access control
>>>> method for DAS/2, the following modifications would be required:
>>>>  - Fix the labels on the HTTP authentication dialog box (blank site
>> and realm)
>>>>  - have IGB properly handle 403 Forbidden responses which may be the
>>>> result of failed login attempts (tons of exceptions)
>>>>  - Determine if IGB's browser cache needs fixing (uses cached file if
>>>> it exists and the current authentication attempt failed)
>>>>  - Modify the DAS/2 servlet to manage access control instead of the
>>>> web.xml (Should be possible, but not certain)
>>>>
>>>> The tomcat context.xml (called das2.xml) and web.xml I used are
>>>> attached. A screen capture of the password dialog box presented by
>> IGB
>>>> is also attached.
>>>>
>>>> Please let me know if I need to clarify anything.
>>>>
>>>> Thanks,
>>>> ~Steven
>>>
>>>
>>
>

From gregghelt at gmail.com  Thu Oct 30 04:02:34 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 01:02:34 -0700
Subject: [DAS2] Minutes from 2 October 2008 DAS teleconference
Message-ID: <50158cb00810300102k3248ad29mdd712c827d6026e8@mail.gmail.com>

Better-late-than-never minutes from 2 October 2008 DAS teleconference:

*Roll Call:*
Gregg Helt (unaffiliated: DAS/2, visualization, data modelling)
Suzi Lewis (LBNL: Apollo, etc.)
Ed Lee (LBNL: Apollo, annotation data models)
Ann Loraine (UNC: plant genomics, genomics vizualization)
Jon Nicols (UNC: genomics visualization )
Steven Blanchard (UNC: sys admin, security)
Andy Jenkinson (EBI: coordinator for DAS services at EBI)
Jonathon Warren (Sanger: coordinator for DAS services at Sanger)
Felix Kozinski (Sanger: DAS coordinator for Sanger ENCODE project)

*DAS/2 Status Summary:*
Gregg gave overview, refer to "DAS/2 Grant Final Progress Report" post
(October 2nd, 2008) on DAS/2 mailing list:
http://lists.open-bio.org/pipermail/das2/2008-October/000438.html
Stuff in summary not covered in progress report:
Alan Day is no longer at UCLA, and not working on the biopackages DAS/2
server (chado, BioPerl based DAS/2 server)
Possibility of deploying biopackages DAS/2 server on a MOD chado
installation (BOP? VectorBase?)
Several people at annotation workshop are using Apollo for curation
alongside IGB for viewing dense quantitative data.

*Hinxton DAS1 Summary*
Registry:
    now have DAS1 registry
    was one of the major things missing from DAS1 that motivated DAS2
    most clients use the registry
    about 400 sources in the registry
    implements validation
    uses same sources command as DAS/2
extensions
    alignments
    structures
    interactions
    in general evolving into a much wider system for biodata
core client/server implementations maintained at Sanger and EBI
lots of other implementations using DAS1, so heavy investment in DAS1
writeback
    one preliminary implementattion (partly based on DAS/2 writeback spec),
but nothing solid yet
    grant application being submitted December 8th
        collab between Sanger, EBI, and NBN (South Africa)
        includes writeback component (client and server implementations)
        client will be in DASTY
translation/bridge between protein and genomic space
        another goal of Sanger/EBI/NBN grant in preparation
Revising DAS1 spec (DAS 1.6)
    refer to biodas wiki pages:
        http://www.biodas.org/wiki/Spec_Review
        http://www.biodas.org/wiki/DAS_Plans
    no changes yet to sources, folded in as is from extensions, deprecate
dsn
"DAS is the general weapon of choice for integrating data throughout Sanger,
and largely at EBI as well"


*Other spec revision:*
DAS/2 spec frozen in November 2006, Gregg feels its time for revision
regardless of other integration, should make sure sources spec evolves in
sync between DAS1/2
Gregg's revisions: Two Plans
    #1.  DAS 2.1 --> relatively minor revisions to spec
    #2   no name yet --> much larger change
            possibly integrating DAS1 and DAS2
            move on top of Atom/AtomPub/GoogleData stack

*Andy -- DAS1 and DAS2*
    #2 above seems to be a good direction to go in from a technical
standpoint
    but, DAS/2 as it stands also seems to be good from a technical
standpoint
    major sticking point is backward compatibility with DAS1
    doesn't see how can convince powers that be to commit to DAS/2 without
backward compat
    other alternative is if there's a proxy that is very successful at DAS1
--> DAS/2 conversion
    Gregg -- still working on proxy, has expanded scope
            about a week away from usable
            proxy: DAS1.53 - dsn + sources
            source code going up on google code project hosting

*DAS2 Funding*
    Ann: recently awarded grant includes funding for DAS/2 arabidopsis
server
            wants to expand to cover many plants
            hopefully deployed at TAIR
            Suzi -- TAIR is using Apollo
            visualization
            UI improvements to IGB
            surveying different genomics visualization tools
            want to have easy way for small data providers to host data
            support/development of GenoViz toolkit
    Gregg:
           Lincoln committed to putting someone on DAS/2 client/server
support for GBrowse
           Gregg, Suzi, Ian Holmes discussing putting in distributed
annotation grant
                submit to NIH Feb 2009
                combine ideas and code from Apollo, JBrowse, IGB, DAS/2
                GMOD help desk now at UNC -- may be interested in joining in

    Andy -- prospects for grant focused on DAS itself as opposed to DAS
within other projects?
    Gregg -- problematic.  already had DAS/2 grant from NIH
    Suzi -- NIH now wants biology driving projects -- plain infrastructure
things don't tend to fly
    Gregg -- maybe could get funding again, but first need more results from
initial DAS/2 grant
                tried big reup three years ago, didn't fly
                need to get a paper out, more sites using
    Andy -- what would help is involvement of major institution
    Gregg -- but we tried with UCSC and PDB in reup, may have helped but
still didn't get funding
                involvement of major data repository necessary but not
sufficient for funding
    Andy -- in Europe industry partnership very important when asking for
funding now
            possibility of funding to build network of integrated EBI
resources based on DAS,
            that industry could use,
            possibility of money from UK/Europe, but probably need to use
what funding already have
    Ann -- what about developing a web services RCN (Research Coordination
Network) via NSF
            example: Microarray Coordination Network
            includes outreach
            in plant community people are using BioMoby a lot, but it's
complicated to use?
            Ann will look into NSF RCN funding possiblities
            iPlant (NSF)
    Sanger and EBI funding for DAS comes mostly from core informatics funds
    Andy -- discuss joining DAS1 and DAS2 in NSF proposal?
               would want institutes on both sides of the pond
    Suzi -- UCSC over here?
    Gregg -- I think they'd be amenable


*Action Items:
*schedule for DAS/2 teleconferences: every other Thursday @ 9AM PST
what are we talking about at the next one?
        get specific about specification changes
        start listing specific aims for grant proposals

From gregghelt at gmail.com  Thu Oct 30 06:31:42 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 03:31:42 -0700
Subject: [DAS2] authentication: don't bake anything into the spec
Message-ID: <50158cb00810300331w2ea4c9d7lf5ebbab25d79395b@mail.gmail.com>

As part of our review of different authentication mechanisms to integrate
into the DAS specification(s), I volunteered to summarize the pros and cons
of the null hypothesis.  That is, not "blessing" any particular
authentication strategy in the DAS protocol itself, but rather leaving
authentication to be determined by the server and client implementations
that need it.

To avoid too many double negatives, I'll flip that around and discuss pros
and cons of having any authentication embedded in the spec.

Cons of having authentication strategy embedded in the DAS protocol:

1) Increases spec complexity.

2) If it's required, then increases development overhead for client and
server implementations that don't need it or need to use an alternative
strategy.

3) May negatively impact adoption by some organizations.  Blessing a
particular authentication strategy, even if alternatives are allowed, can
have a dampening effect on adoption by organizations that need to use an
alternative strategy.  In other words, the protocol may be viewed as being
optimized for the blessed strategy at the expense of others, increasing the
chances of a more agnostic alternative being adopted instead.  Even if the
bioinformatics folks at an organization want to use DAS, in many
organizations (at least the corporate ones) they have little influence on
security-related technology decisions.

Pros of having authentication embedded in the DAS protocol:

1) More likely that client and server implementations can be used "off the
shelf" as long as the authentication needed is met by the blessed strategy

2) By virtue of (1), may positively impact adoption by some organizations

3) Promotes uniformity across various implementations

From gregghelt at gmail.com  Thu Oct 30 08:17:15 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 05:17:15 -0700
Subject: [DAS2] DAS URI resolvability
Message-ID: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>

Sorry, I think I confused the issue again -- I seem to be on a terminology
abuse binge.  I used "addressable" and "addressability" in referring to URIs
when I should have used "identifiable" and "identifiability".  Please
mentally do s/addressable/identifiable/g and
s/addressability/identifiability/g on everything I've written in the past
week...

I think you and I are in agreement as far as whether DAS URIs should be
resolvable.  Quoting myself from a previous thread I forwarded to the list
last night (with terminology corrections applied):

In general as part of a spec revision (DAS 2.1?) I'd like to eliminate more
of the resolvability requirements in the specification, and specify that
most URIs be used as identifiers with _optional_ resolvability.  After two
years of working with the current spec I've come to believe that for most
cases requiring resolvable URIs is not necessary, places added burden on
server implementations, and limits the ability to do non-authoritative
decentralized annotation.

The spec can be stripped down so that the only URI references required to be
resolvable are those specified by the "query_uri" attribute of the
CAPABILITIES element.

The only problematic part in the DAS/2 annotation retrieval spec would be
the segment URIs.  The current spec needs these to be resolvable as that's
the mechanism used to retrieve residues for a particular segment/sequence.
But I think this could be revised without too much implementation overhead
to merge residues retrieval and the segments query to make something more
like a hybrid of the DAS2.0 segments and DAS1.53 sequence queries.

       Gregg

On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk>wrote:

> The difference between an ID and a URI is not so great, any ID can be a URI
> if we refer to the URN definition. But whether this URI should be resolvable
> (that is, a URL) is a big question. Whilst it is certainly a nice thing to
> be able to do, I'm not convinced of the practicality given the relationship
> between simplicity and adoption of technologies like DAS.
>
> Ignoring the difficulty in making something actually resolvable (which can
> potentially be accomplished for features by just having "
> http://server/das/source/features?feature_id=foo") there is more pressure
> than ever on keeping verbosity low, and I'm not sure if this can be
> accomplished as things are right now when you have different URI prefixes in
> the same document. Gregg, perhaps you can elaborate?
>
> I know you also advocate alternative content negotiation to solve this
> issue - do your alternative formats contain these URIs or do they strip
> them?
>
> Gregg Helt wrote:
>
>> Using the DAS/2.0 specification, this idea of "annotations of annotations"
>> is easy to do.  That's because every feature in DAS/2.0 has a unique URI and
>> is therefore addressable by _any_ other system that uses URIs -- including
>> another DAS/2.0 server:
>>
>> <FEATURE uri="http://somewhere.else/feat123" ... >
>>     <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue XYZ"
>> />
>> </FEATURE>
>>
>> Or if you prefer allowing your meta-annotation to have it's own URI:
>>
>> <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>
>>
>> Used in this way DAS/2.0 becomes very RDF-like..
>>
>> This is not just a happy accident but the result of a central tenet of
>> DAS/2 -- addressability of all important DAS/2 entities outside the local
>> system via URIs.  The DAS/2 writeback spec is built on top of the DAS/2
>> retrieval spec, so if you're fully implementing the writeback spec you
>> should be able to use this ability to do meta-annotations.
>>
>>      Gregg
>>
>

On Wed, Oct 29, 2008 at 3:15 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Gregg Helt wrote:
>
>>
>> Sorry for being imprecise about URIs, what I meant to say was that every
>> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
>> relative URIs but not absolute URIs, and referring to relative URIs is not
>> particularly useful outside their context.
>>
>
> By relative URI do you mean URN (e.g. SO:12345)? As opposed to the HTML
> definition (e.g. index.html). URNs are still useful since they allow us to
> solve this issue of identifying things that are the same. A resolvable URI
> (i.e. a URL) is undoubtedly "better", but this is semantic web territory and
> I'm not convinced it is necessary for DAS. Certainly I think it would be too
> much a constraint to layer onto the existing spec in one increment. In fact
> even using URNs is not easy for everything - segment IDs cannot have colons.
>
>

From andy.jenkinson at ebi.ac.uk  Thu Oct 30 10:09:46 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:09:46 +0000
Subject: [DAS2] DAS URI resolvability
In-Reply-To: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>
References: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>
Message-ID: <4909C02A.30501@ebi.ac.uk>

Gregg Helt wrote:
> Sorry, I think I confused the issue again -- I seem to be on a 
> terminology abuse binge.  I used "addressable" and "addressability" in 
> referring to URIs when I should have used "identifiable" and 
> "identifiability".  Please mentally do s/addressable/identifiable/g and 
> s/addressability/identifiability/g on everything I've written in the 
> past week...
> 
> I think you and I are in agreement as far as whether DAS URIs should be 
> resolvable.  Quoting myself from a previous thread I forwarded to the 
> list last night (with terminology corrections applied):
> 
> In general as part of a spec revision (DAS 2.1?) I'd like to eliminate 
> more of the resolvability requirements in the specification, and specify 
> that most URIs be used as identifiers with _optional_ resolvability.  
> After two years of working with the current spec I've come to believe 
> that for most cases requiring resolvable URIs is not necessary, places 
> added burden on server implementations, and limits the ability to do 
> non-authoritative decentralized annotation.
> 
> The spec can be stripped down so that the only URI references required 
> to be resolvable are those specified by the "query_uri" attribute of the 
> CAPABILITIES element. 

Great, I think we're on the same page.

> The only problematic part in the DAS/2 annotation retrieval spec would 
> be the segment URIs.  The current spec needs these to be resolvable as 
> that's the mechanism used to retrieve residues for a particular 
> segment/sequence.  But I think this could be revised without too much 
> implementation overhead to merge residues retrieval and the segments 
> query to make something more like a hybrid of the DAS2.0 segments and 
> DAS1.53 sequence queries.

Keeping one eye on our plans for the future, I think it's worth bearing 
in mind that DAS has many more "coordinate systems" than genome 
assemblies, and only some of these are sequence.

DAS clients need to be able to get:
1. a list of reference entities
2. reference data (sequence, structure) for a single entity
3. annotation data (features, interactions) for a single entity

We could combine 1 and 2 as you suggest, but the size of the data would 
mean it would have to emulate separate command (i.e. get me a list of 
sequences, but don't give me the sequence) so we might as well keep them 
separate (e.g. entry_points + sequence; entry_points + structure).

Incidentally, the concept of a segment is far less important in DAS now 
so it's probably too specific as a command name (shout if that needs 
explanation...).

From andy.jenkinson at ebi.ac.uk  Thu Oct 30 10:24:54 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:24:54 +0000
Subject: [DAS2] [DAS] [Fwd: Re:  Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk>
	<4908837C.1000902@nbn.ac.za>	<490891A4.8050908@ebi.ac.uk>
	<4909821B.6050300@nbn.ac.za>
Message-ID: <4909C3B6.4060104@ebi.ac.uk>

Gustavo Salazar wrote:
> Now that all of you points about the URI field, i have notice that in 
> the Asia's implementation the attributes of the FEATURE tag have changed 
> in relation of the examples in the published protocol( 
> http://biodas.org/documents/das2/das2_writeback.html), and for example 
> there is not a uri attribute and is replaced by featureid, the example 
> for the tag FEATURE in her document is:
> 
> <FEATURE featureid="ADCK2" featuretype="exon" method="experiment">

I would have expected the <FEATURE> structure to be the same as the 
features command, could a DAS/2 person comment on the difference?

So long as the data relationships are the same I guess it doesn't matter 
(i.e. one type, which has an ID, a category and label; one method...). 
But does it?

One difference I have noticed between DAS and DAS/2 is that in the 
latter a method is an attribute of a type rather than a feature - this 
means you can't have two features, both of type SNP, identified by 
different methods... I believe it's implemented this way in the DAS 
types command too, and I'm planning to remove it from the spec.

> I have also notice that for properties in that implementation is used a 
> tag <PROPERTY> but Gregg used <PROP> in his example

This changed at some point - I believe PROP is correct.

From andy.jenkinson at ebi.ac.uk  Thu Oct 30 10:28:14 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:28:14 +0000
Subject: [DAS2] [DAS] [Fwd: Re:  Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk>
	<4908837C.1000902@nbn.ac.za>	<490891A4.8050908@ebi.ac.uk>
	<4909821B.6050300@nbn.ac.za>
Message-ID: <4909C47E.4070302@ebi.ac.uk>

Gustavo Salazar wrote:
> Hello,
> 
> Thanks for your comments.
> 
> In the Asia's implementation the ADD command is implemented by default 
> i.e. that if the UPDATES or DELETES tags doesn't appears the writeback 
> document is understood as an addition. I am implementing this in the 
> same way.

This seems fair.

> About the use of UPDATE instead of setCurrent is a good idea easier to 
> implement in client and server, however the getHistorical command still 
> looking to me as necessary.

Provenance is an important thing so functionality of this nature is 
something I would like to see. I expect this is something that anyone 
looking to use writeback in a genome annotation context would want too, 
perhaps Suzi could comment?

From gregghelt at gmail.com  Thu Oct 30 11:20:09 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:20:09 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4909C3B6.4060104@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
	<4909C3B6.4060104@ebi.ac.uk>
Message-ID: <50158cb00810300820r4a0c528brb7bdea6331224eca@mail.gmail.com>

In the DAS/2 writeback spec (
http://biodas.org/documents/das2/das2_writeback.html), the <FEATURE>
structure is the same as that returned in the DAS/2 features query, with the
single addition of an "old_uri" attribute in the writeback response.

Asia implemented things differently, and the result partly follows the DAS/2
writeback spec, but with bits of DAS1 and other things mixed in.  There's a
discussion of these changes in her master's thesis on the writeback
implementation (
http://daswriteback.googlecode.com/files/Thesis_corrected.pdf ).

On Thu, Oct 30, 2008 at 7:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Gustavo Salazar wrote:
>
>> Now that all of you points about the URI field, i have notice that in the
>> Asia's implementation the attributes of the FEATURE tag have changed in
>> relation of the examples in the published protocol(
>> http://biodas.org/documents/das2/das2_writeback.html), and for example
>> there is not a uri attribute and is replaced by featureid, the example for
>> the tag FEATURE in her document is:
>>
>> <FEATURE featureid="ADCK2" featuretype="exon" method="experiment">
>>
>
> I would have expected the <FEATURE> structure to be the same as the
> features command, could a DAS/2 person comment on the difference?
>
>
>

From gregghelt at gmail.com  Thu Oct 30 11:27:00 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:27:00 -0700
Subject: [DAS2] Fwd: A case for why we need authentication/ login
	functionality in the DAS specifications
In-Reply-To: <C51E28AA.5F8F%david.nix@hci.utah.edu>
References: <C51E28AA.5F8F%david.nix@hci.utah.edu>
Message-ID: <50158cb00810300827o56738242t8f86363d87559807@mail.gmail.com>

On Thu, Oct 30, 2008 at 7:47 AM, David Nix <david.nix at hci.utah.edu> wrote:
Hey Gregg, I don't think my summary went out to the das mailing lists.  It
came back last week rejected for lack of permission to post.  Could you
forward it?  -cheers, D


---------- Forwarded message ----------
From: David Nix <david.nix at hci.utah.edu>
Date: Fri, Oct 17, 2008 at 10:34 AM
Subject: A case for why we need authentication/ login functionality in the
DAS specifications
To: das2 at lists.open-bio.org, Gregg Helt <gregghelt at gmail.com>, Tonya DiSera
<tony.disera at hci.utah.edu>, Brett Milash <brett.milash at hci.utah.edu>, Robb
Cundick <robb.cundick at hci.utah.edu>, Ann Loraine <aloraine at gmail.com>,
Steven Blanchard <sgblanch at gmail.com>, Suzanna Lewis <suzi at berkeleybop.org>,
Andy Jenkinson <andy.jenkinson at ebi.ac.uk>


Hello Folks,

Here is a case for why we need authentication/ login functionality in DAS.

Key Functionality: Need a mechanism to tell a DAS server who is making a
particular request.

This will enable tailor-made responses such as:

1) Access to private data (sources, segments, types, etc.)
2) Custom views of the data (investigator view vs clinic view of same data)
3) Restricted write back
4) Support future as of yet undefined personalized responses

How this is implemented is of little concern to me so long as the key
functionality is met.

That said, a couple of considerations for any DAS Server implementation:

1) Web forms/ GUIs should be capable of modifying the users, user
permissions, data views and uploading of new data. Privileged users with no
command line skills (ie biologists/ lab managers) need to be able to
customize their data and who can see it. They shouldn't have to make a
request to a system administrator.

2) The mechanism of passing the user credentials to the servlet should be
platform independent. The fewer barriers to installing a DAS server the
better. A good DAS server should support authentication on WebSphere,
Tomcat, Orion, etc. with little to no modification.

A first stab:

I've build into the current GenometryDas2Servlet a mechanism for
authenticating a client. I tried to follow existing DAS/2 query/ response
styles.

In brief, I created a new DAS command called 'login' that prompts the
servlet to check to see if this server instance is authorizing. If it is not
authorizing (ie contains no restricted sources/segments/types) then an xml
doc is returned with an AUTHORIZED tag set to true. If it is authorizing and
no login parameters are provided with the request then the AUTHORIZED tag is
set to false. If the server doesn't recognize the login request then it's
HTTP ERROR: 400 response also says it isn't accepting authorization.

Thus a login request without parameters basically is asking to see if
authentication is recognized and, if so, enabled.

If 'user' and 'password' parameters are supplied with the 'login' request,
the servlet attempts to authenticate the user, if OK an HTTPSession object
is created for the user, a JSESSIONID is attached to the xml response as a
cookie and the AUTHORIZED tag set to true.

I modified IGB to make a 'login' request to each DAS/2 server listed in it's
igb_pref.xml file upon start up. If the DAS/2 server responds appropriately,
IGB asks the user to enter a login and password.  These are then sent as
plain text parameters (bad, need a better mechanism, https?) with a second
login request. Authentication then proceeds.  If the server doesn't
recognize the login request (throws an HTTP ERROR: 400) or it isn't enabled,
the user isn't prompted and no login information is sent. See the attached
file for some examples of the exchange.


-cheers, David


--
David Austin Nix, PhD | HCI Bioinformatics | Huntsman Cancer Institute |
2000 Circle of Hope | SLC, UT 84112 | Rm: 3344 | Vc: 801.587.4611 | Fx:
801.585.6458 | david.nix at hci.utah.edu |
http://bioserver.hci.utah.edu/BioInfo/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loginResponses.xml
Type: text/xml
Size: 1349 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/das2/attachments/20081030/1729334b/attachment-0001.xml>

From gregghelt at gmail.com  Thu Oct 30 11:36:17 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:36:17 -0700
Subject: [DAS2] A case for why we need authentication and login
	functionality in the DAS specifications
Message-ID: <50158cb00810300836j75f4289fya593fc7fb74ec59@mail.gmail.com>

On Thu, Oct 30, 2008 at 7:47 AM, David Nix <david.nix at hci.utah.edu> wrote:
Hey Gregg, I don't think my summary went out to the das mailing lists.  It
came back last week rejected for lack of permission to post.  Could you
forward it?  -cheers, D

---------- Forwarded message ----------
From: David Nix <david.nix at hci.utah.edu>
Date: Fri, Oct 17, 2008 at 10:34 AM
Subject: A case for why we need authentication/ login functionality in the
DAS specifications
To: das2 at lists.open-bio.org, Gregg Helt <gregghelt at gmail.com>, Tonya DiSera
<tony.disera at hci.utah.edu>, Brett Milash <brett.milash at hci.utah.edu>, Robb
Cundick <robb.cundick at hci.utah.edu>, Ann Loraine <aloraine at gmail.com>,
Steven Blanchard <sgblanch at gmail.com>, Suzanna Lewis <suzi at berkeleybop.org>,
Andy Jenkinson <andy.jenkinson at ebi.ac.uk>

Hello Folks,

Here is a case for why we need authentication/ login functionality in DAS.

Key Functionality: Need a mechanism to tell a DAS server who is making a
particular request.

This will enable tailor-made responses such as:

1) Access to private data (sources, segments, types, etc.)
2) Custom views of the data (investigator view vs clinic view of same data)
3) Restricted write back
4) Support future as of yet undefined personalized responses

How this is implemented is of little concern to me so long as the key
functionality is met.

That said, a couple of considerations for any DAS Server implementation:

1) Web forms/ GUIs should be capable of modifying the users, user
permissions, data views and uploading of new data. Privileged users with no
command line skills (ie biologists/ lab managers) need to be able to
customize their data and who can see it. They shouldn't have to make a
request to a system administrator.

2) The mechanism of passing the user credentials to the servlet should be
platform independent. The fewer barriers to installing a DAS server the
better. A good DAS server should support authentication on WebSphere,
Tomcat, Orion, etc. with little to no modification.

A first stab:

I've build into the current GenometryDas2Servlet a mechanism for
authenticating a client. I tried to follow existing DAS/2 query/ response
styles.

In brief, I created a new DAS command called 'login' that prompts the
servlet to check to see if this server instance is authorizing. If it is not
authorizing (ie contains no restricted sources/segments/types) then an xml
doc is returned with an AUTHORIZED tag set to true. If it is authorizing and
no login parameters are provided with the request then the AUTHORIZED tag is
set to false. If the server doesn't recognize the login request then it's
HTTP ERROR: 400 response also says it isn't accepting authorization.

Thus a login request without parameters basically is asking to see if
authentication is recognized and, if so, enabled.

If 'user' and 'password' parameters are supplied with the 'login' request,
the servlet attempts to authenticate the user, if OK an HTTPSession object
is created for the user, a JSESSIONID is attached to the xml response as a
cookie and the AUTHORIZED tag set to true.

I modified IGB to make a 'login' request to each DAS/2 server listed in it's
igb_pref.xml file upon start up. If the DAS/2 server responds appropriately,
IGB asks the user to enter a login and password.  These are then sent as
plain text parameters (bad, need a better mechanism, https?) with a second
login request. Authentication then proceeds.  If the server doesn't
recognize the login request (throws an HTTP ERROR: 400) or it isn't enabled,
the user isn't prompted and no login information is sent. See the attached
file for some examples of the exchange.


-cheers, David


--
David Austin Nix, PhD | HCI Bioinformatics | Huntsman Cancer Institute |
2000 Circle of Hope | SLC, UT 84112 | Rm: 3344 | Vc: 801.587.4611 | Fx:
801.585.6458 | david.nix at hci.utah.edu |
http://bioserver.hci.utah.edu/BioInfo/

From Steve_Chervitz at affymetrix.com  Thu Oct 30 14:56:43 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 30 Oct 2008 11:56:43 -0700
Subject: [DAS2] Minutes from 30 Oct 2008 DAS teleconference
Message-ID: <C52F517B.33040%Steve_Chervitz@affymetrix.com>

Action items are now summarized at the end of the minutes.

Steve

------------------------------------------------------------------
Minutes from 30 Oct 2008 DAS teleconference

Teleconference Info:
   * Schedule:         Biweekly on Thursday
   * Time of Day:      9:00 AM PDT, 12:00 PM EST, 16:00 GMT
   * Dialin:           See biodas.org community portal page for details

Attendees: 
    Free agent: Gregg Helt
    Affymetrix: Steve Chervitz
    EBI: Andy Jenkinson
    Sanger: Jonathan Warren, Felix Kokocinski
    U North Carolina: Ann Loraine, Steven Blanchard, John Nicol

Note taker: Steve Chervitz

Action items are flagged with '[A]' and are summarized at the bottom of the
minutes.

The teleconference schedule and links to past minutes are
available from the Community Portal section of the biodas.org site:
http://www.biodas.org/wiki/BioDAS:Community_Portal#Teleconference

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit on the the discussion list.

========================================================

Agenda:
========

* Review progress on action items from last week (based on minutes)
* Gregg give overview of the Trellis/Ivy DAS1-->DAS2 proxy, and future plans


Discussion of action items from 16 oct 2008 teleconf:
=====================================================

Previous action items are underlined, with relevant discussion below.

Suzi: Decide Ian or Suzi is PI on grant. Issue reciprocal letters of collab.
----------------------------------------------------------------------------
--------------

(Pending)  - Suzi is not on this call.

Steve: Combine das and das2 lists. Can they be merged.
--------------------------------------------------------------

SC: Plan is to ultimately have a single das discussion list. Everyone
on das2 list that is not on the das list will be added. Then we can
redirect any posts to the das2 list to go to the das list. Das2 list
will be retained as an archive.

I have been added as an admin on the das list, so now I can work on
migrating users. Also need to update the list description per the new
arrangement.  Haven't had a chance to do this, but will get on it by
mid-next week.

Noticed a fair amount of spam sent to the list that needs
moderation. Original moderators are no longer active.

AJ: We can have the list auto reject messages from non-subscribers.

SC: Good idea. Will reduce moderation burdon.

AJ/JW: Willing to be added as moderators.


Suzi: Summation of authentication pros and cons. Review descriptions, make a
decision.
----------------------------------------------------------------------------
--------------

(Pending)

Gregg will forward our off-list discussions to the list to get input from
others.
----------------------------------------------------------------------------
----

GH: See other's posts to the list. GH's summary.

Gregg will send out side-by-side DAS/1 and DAS/2 UML models (pictures and/or
model files).
------------------------------------------------------------------------

GH: See 29-oct-08 post to the list for these.
JW: Could get technical, esp. for alignments.
GH: Teleconf can be more efficient than email, though face-to-face is best.
AJ: Can put it at the end of the discussion.

Gregg: write proposed changes to sources document more formally.
----------------------------------------------------------------------

(Pending)

UK folks: Continued Das integration work (spec review)
-------------------------------------------------------

JW: No comments posted. Planning to try RNG instead of XSD. Good
suggestion. Working on validation. Will post these next week.

GH: There is a nice RNC mode in emacs, and in-line realtime validator that
will
validate against a document.


Anyone interested in contributing: look at links from Andy/Jonathan on how
das1 is changing.
----------------------------------------------------------------------------
-------------

GH: Regarding DAS changes document, I can start editing with how it
changes for DAS/2. But could get long.
JW: That's fine.

GH: Regarding plans to deprecate the DSN: I like this, but will
require changes to the sources document to fully deprecate
it. Example: Map masters not reflected in the registry.
JW: OK. We're open to any changes.

Steve: wikify the HTML docs.
-------------------------------

SC: Wikified as of last night (10/29). Left-hand nav of biodas.org
link has been updated and DAS/2 page updated to point to wikified spec
at http://www.biodas.org/wiki/DAS/2/Spec

AL: Concerned that it is not noted as "under development". There
should be a fixed version of the spec and a draft version so that
people know what they're using.

SC: Can flag the wikified spec as "evolving" and have pages be
DAS/2.1. The HTML version of the spec can be flagged as "frozen".
Will post a link to the list when ready.


All: Teleconf in two weeks, same time, but need better phone line!
----------------------------------------------------------------------

New number for this meeting is not long-term (GH is paying for).
GH: Can probably use Suzi's long-term. Her laptop is offline
currently, but we should be able to get the info before next meeting.


New Topics
============

JW: DAS workshop at Hinxton on 9-11 March. Tutorial day1, das
project talks das2, hackathon day3, more programming work, das1-2
merging, etc. Not tied to other meeting. Sponsored by BioSapiens.

GH: Love to attend, but need funding. Would like to host a workshop on
West coast at some point. Prob best time 6 mos after UK. Hackathon-style.

SC: Can you post it to biodas.org current events?

AJ/JW: It's not yet been announced. Will do eventually.

AL: Working on changes to das server to support Arabidopsis data and
also some IGB mods. Will test before posting. Hosting of bioviz.org.

Plan to host Java Web start for IGB on bioviz.org, based on SVN
codebase in SF.  

JN: The Affy links to launch IGB on the SF page are broken.

[A] Steve: Fix Affy IGB launching links on SF page.

SC: You will need a code signing certificate because IGB needs to
write to the local disk. Affy's cert is expiring in December, but
don't need to renew if yours will be ready by then. What's
your time frame?

JN: Can look into getting something preliminary posted soon.

GH: Need a release that can support the translational proxy. Will talk
about this with AL offline.


Topic: Gregg's translational proxy
====================================

GH: Has anyone looked at this yet?
AJ: Have looked at code, not XML. Will check it out.

GH: What it is doing: Das ID -> URI conversion. Hit some issues where
some das IDs aren't really URI or URI refs. Using XML base features of
das2, using a shorthand version of the URI (XML base space provides
way to resolve them into full URIs).

Other stuff: tell if a field (e.g., phase or score) is null or not
available, will strip those out to avoid overhead of empty
elements. When there are values which aren't in DAS/2 protocol,
it converts into das/2 properties with "DAS1:" prefix. Seems to work
well. Looked at some examples, none of which had non-nulls, so you
can't see this. Will post some examples to illustrate.

Other thing (trying to do): Mapmaster in DSN not listed in
registry. Lots of things in registry w/ no pointer to entry points, but
have a shared coord system.

AJ: Don't worry about DSN command now. Every coord sys will have a ref
server that will implement entry points and sequence.
GH: Good. Would like to change this in the doc.
GH: Doing a transitivity thing based on entries with entry points but
not coord systems, or vice versa. With proxy system you can infer
things over multiple sources.

Other things; Proxy taking das1 registry sources --> das2 sources
document, leaves all das1 capabilities in tact, so it has both das1
and das2 (a hybrid).

GH: Test deployment is sitting on Amazon cloud in Genomancer. Want it
hosted on Sanger/EBI closer to the registry, will help for
efficiency. 
JW: Can look at putting it up there. Need to look at the proxy.


Topic: Gregg's Trellis/Vine/Ivy project
===========================================

GH: Trellis project (the foundation for das1->2 proxy). Trellis is a
modular das2 server/servlet framework. Take das2 data model, plug it into
trellis to get a functional das2 server. Plan to move UCSC das2 server
to be a plugin for trellis. Framework deals with query parsing and
generating xml. Plugin is just dealing with data models.

Also das2->2 proxy as well. for das2 server that don't implement alt
content format. A proxy might be able to serve those up.  Vine module
has full das2 client library. To do a full proxy, you need a client.

Ivy: This is the das1 part of the das1->2 proxy.

Pleased with this as a framework for further development. All future das2
work will be on trellis framework. This had a larger scope than
anticipated, hence the extra time to develop.

SC: Any docs?
GH: None, other than UML.

SC: So trellis is framework. Ivy, Vine are plugins?

Noting from Gregg's DAS list post:
  * Trellis: DAS/2 server framework
  * Vine: DAS/2 proxy plugin
  * Ivy: DAS/1 proxy plugin

GH: There's a plugin API in the Trellis servlet specifying that plugin
specifies the sources capability data model, the rest of data model is
under sources. Vine=DAS2 proxy. Much impl can be obtained from that
(e.g., has stubby getters and setters). Plugin dev focus is on
capability API. 


Action Item Summary:
========================

Old action items:
-----------------

[A] Suzi: Decide Ian or Suzi is PI on grant. Issue reciprocal letters of
collab. (16-oct-08)

[A] Suzi: Summation of authentication pros and cons. Review descriptions,
make a decision. (16-oct-08)


New action items:
-----------------

[A] All: Next teleconf in two weeks: 13-Nov-08

[A] All: Anyone that has items they want discussed, send to Gregg.

[A] All: Review Gregg's DAS UML modeling, post any comments to list.

[A] All: Review Gregg's DAS1->DAS2 proxy work (Trellis/Ivy/Vine), post any
comments to list.

[A] AJ: Post info about March '09 Hinxton DAS workshop to
biodas.org/current_events

[A] AJ: Continue checking out Gregg's DAS1->DAS2 proxy, esp. the XML.

[A] GH: Send out action and agenda items well in advance of teleconf.

[A] GH: Add auth and security on the agenda so interested folks can call in.

[A] GH: Solicit feedback about security/auth from interested parties.

[A] GH: Contribute to the DAS changes document re: DAS/2, sources &
deprecating DSN.

[A] GH: Get new teleconf number from Suzi; post to list with agenda.

[A] JN: Post preliminary java web start IGB release on bioviz.org

[A] SC: Merge DAS2 subscribers to DAS list. Redirect DAS2 posts to DAS list.

[A] SC: Consider making DAS list auto reject posts from non-subsribers.

[A] SC: Add Andy J and Jonathan W as admins to the DAS mailing list.

[A] SC: Change 2 -> 2.1 and say it is "evolving"; declare the HTML spec as
"frozen"

[A] SC: Send link to the 2.1 wiki spec to list.

[A] SC: Fix Affy IGB launching links on SF page.

[A] SC: Update biodas.org community portal page with new teleconf number.



----------------------------------------------------------------------------
--------
Minutes are committed to the biodas.org CVS repository under
biodas/das/das2/notes/

$Id: das2-teleconference-2008-10-30.txt,v 1.4 2008/10/30 18:55:42 sac Exp $










From garret at globalmentor.com  Thu Oct 30 18:01:06 2008
From: garret at globalmentor.com (Garret Wilson)
Date: Thu, 30 Oct 2008 15:01:06 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	
	<4908B3C7.5020002@ebi.ac.uk>	
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>	
	<4908E705.8050904@globalmentor.com>
	<50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>
Message-ID: <490A2EA2.90101@globalmentor.com>

Gregg Helt wrote:
> So let me rephrase.  Every feature in DAS/2.0 has a unique URI.  In 
> the feature XML this is represented by the "uri" attribute of the 
> FEATURE element, which is a URI reference (URI or relative URI 
> reference), and optional xml:base attributes in the document.  DAS/2.0 
> uses the XML Base specification <http://www.w3.org/TR/xmlbase/> to 
> resolve relative URI references via xml:base attributes and/or the URI 
> the document is a representation of. 

Sounds like we're all on the same page, then.

This brings up a related issue regarding the assembly and sequence URIs 
at http://www.biodas.org/wiki/GlobalSeqIDs . Before on this list I've 
brought up the issue of whether DAS has authority to maintain 
identifiers in namespaces from domains controlled by third parties (i.e. 
NCBI). This still worries me.

How confident can we be that the DAS GlobalSeqIDs are stable and will 
not change for a while?

Secondly, related to URI resolution, I note that I cannot take an 
assembly URI such as http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/ 
and simply resolve the chromosome ID (e.g. chr1) against it to form the 
sequence URI. My application instead has to have specific knowledge of 
this particular assembly namespace, knowing that it must first append 
the path segment "dna/" to the URI, yielding 
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/dna/chr1 .

I'd rather my application, once it knew the assembly URI, simply need to 
resolve the chromosome ID to the assembly URI to determine the sequence 
URI, such as http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/chr1 .

Garret

From Steve_Chervitz at affymetrix.com  Thu Oct 30 21:56:52 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 30 Oct 2008 18:56:52 -0700
Subject: [DAS2] DAS/2.1 spec wiki link
Message-ID: <C52FB3F4.330CC%Steve_Chervitz@affymetrix.com>

Here's the updated link to the new wikified version of the DAS/2.1 spec, the
version that we are free to evolve toward the next version of the spec, as
we work jointly on DAS/1.x and DAS/2.x issues:

http://www.biodas.org/wiki/DAS/2.1/Spec

It's clearly distinguished from the stable 2.0 version that exists as a
static HTML document.

The only section in the 2.1 spec that has content is the retrieval portion
for genomic data:
http://www.biodas.org/wiki/DAS/2.1/Spec/Get-Genomic

Which has been split into separate wiki pages for each DAS/2 document type:
sources, segments, types, features. The other parts (stylesheet, writeback,
region locking, etc.) can be incorporated eventually.

The content of the retrieval spec was taken directly from the DAS/2.0 HTML
document, with enough edits to make it look reasonable in the wiki.  The
overview and details sections for each document type were combined on the
same page. We might want to combine the various example sections into one
(in the HTML doc, there were separate examples in the overview and details
section, which I preserved).

Have fun,
Steve

------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.

From gregghelt at gmail.com  Fri Oct 31 05:12:26 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 02:12:26 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
Message-ID: <50158cb00810310212i3a44b91ev30244955818796db@mail.gmail.com>

The DAS/2 writeback spec uses a RelaxNG schema to define the writeback XML.
The schema is at http://biodas.org/documents/das2/writeback.rnc and
references the DAS/2 retrieval spec's schema at
http://biodas.org/documents/das2/das2_schemas.rnc .  Just noticed the schema
isn't referenced in the HTML spec doc, so I've now added a link.

     Gregg

On Thu, Oct 30, 2008 at 2:44 AM, Gustavo Salazar <gustavo at nbn.ac.za> wrote:

>
> Then i am wondering if there is a DTD or XML-schema that defines those
> documents, because obviously those small changes becomes a problem during
> the parsing of the file.
>
> Cheers,
>
> Gustavo.
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>

From gregghelt at gmail.com  Fri Oct 31 07:45:38 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 04:45:38 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <49087FF9.5080704@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
Message-ID: <50158cb00810310445x28f3aae4sa2a4b2d9955c3c82@mail.gmail.com>

All this discussion is getting me excited about writeback again!


>> 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 like that you're starting out with MyDas.  When I started work on the
DAS1-->DAS2 proxy project I reviewed the various Java-based DAS1
implementations available (including my own previous DAS1 client and server
work), and also decided to start with MyDas for the DAS1 side of the proxy.
For DAS1.53 MyDas seems to hit the sweet spot in terms of completeness
combined with low complexity.

When what was initially a DAS1-->DAS2 proxy project expanded to include a
general DAS2 server framework, DAS1 client, DAS2 client, and more, I
realized that I was really making too many fundamental changes to my copy of
MyDas and ended up redoing the DAS1 side  to use a completely new DAS1 data
model.  But even though there's no MyDas code in the proxy anymore, there's
definitely ideas from MyDas in there.

But I digress.  What I really wanted to say is that you might be able to
leverage parts of Trellis (my DAS2 server framework) and Ivy (the DAS1 proxy
plugin for Trellis) for your writeback project.  As mentioned earlier in
this thread, the DAS2 writeback spec relies on the DAS2 retrieval spec for
feature, type, etc. XML.  So if you're implementing the DAS2 writeback spec
and using MyDas on the server side, you're going to need some way of
transforming DAS2 features sent to the server in the writeback request into
the MyDas DAS1 model (or else implement a DAS2 model in MyDas).  And you'll
also need to transform DAS1 features in MyDas into DAS2 features for the
writeback response, so the transformations are bidirectional.  I think code
in Trellis and Ivy could help with these transformations.

One of the perks of Trellis is that for use with any existing Java-based
DAS1 or DAS2 server, there are several potential levels of integration.  For
DAS1 servers:

1) Separate servers: Use Trellis/Ivy as a transformational proxy server,
acts as a DAS1 client to the proxied DAS1 server.
2) Integrate by writing mapping code to transform between existing DAS1
server data model and Ivy DAS1 data model, rely on Ivy to transform from Ivy
DAS1 model to Trellis DAS2 model.
3) Integrate by writing mapping code to transform between existing DAS1
server data model and Trellis DAS2 data model.
4) Reimplement existign DAS1 server to use Trellis DAS2 data model directly.

Going down this list the level of integration with Trellis increases, and
thus so does the efficiency of the resulting DAS2 server (fewer
transformations), but the implementation overhead also increases.  So groups
that are interested in using Trellis have different options to choose from
based on their preferences/needs for implementation overhead vs. server
performance.  There's a similar list of three levels of integration for
existing DAS2 servers:

A) Separate servers: Use Trellis/Vine (Vine is the DAS2 proxy plugin for
Trellis) as a transformational proxy server, acts as a DAS2 client to the
proxied DAS2 server.
B) Integrate by writing mapping code to transform between existing DAS2
server data model and Trellis DAS2 data model
C) Reimplement existing DAS2 server to use Trellis DAS2 data model directly.

My intent is to start integrating Trellis with various DAS1 servers via (2),
and DAS2 servers via (B) and/or (C).  My short list of Trellis integration
projects, listed by estimated difficulty level:

      MyDas DAS1 server
      UCSC-based DAS2 server I've been working on
      Dazzle DAS1 server
      Genometry DAS2 server

Given that the Ivy DAS1 data model borrows ideas from MyDas, integrating
Trellis and Ivy via (2) above should be pretty straightforward.  Which would
essentially yield the MyDAS-->DAS2 half of the bidirectional transform
mentioned above for writeback implementation.  I think the DAS2-->MyDAS
other half of the transform would also fit well into the Trellis framework,
though I haven't given as much thought to that yet.

Are you interested in this approach?  If so, I'm interested in working on
this MyDAS<-->Trellis integration.  What's your timeline?  That may help
determine my project priorities over the coming months.

     Gregg

From gregghelt at gmail.com  Fri Oct 31 13:34:44 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 10:34:44 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <490B1490.6090900@gmail.com>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
	<50158cb00810310212i3a44b91ev30244955818796db@mail.gmail.com>
	<490B0CE0.5070708@nbn.ac.za> <490B1490.6090900@gmail.com>
Message-ID: <50158cb00810311034y62ecbe24yc13f77d04fd01e6d@mail.gmail.com>

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.


> Just to reinforce what you are saying about Dasty being a 1.53 client, it's
> important that we're clear about the goals of your project: to add writeback
> to DAS (as it is currently) via Dasty. This is independent of DAS/2. If
> Gregg's code can help you it of course makes sense to use it, but you do not
> have to support all of DAS/2's data model.
>

Agreed.  I don't mean to divert Gustavo's project from it's goals.  I just
wanted to point out that if the intent is to implement the current DAS/2
writeback spec that implies use of parts of the DAS/2 retrieval spec as
well.  And if the intent is also to use MyDas then that implies some
DAS1<-->DAS2 transformations will be needed, in which case the Trellis/Ivy
code base could be useful.

Reading the DAS2 writeback spec for the first time in a while I see that
there are a few bits that need to be expanded.  But I also see parts that
could be simplified.  Possibly simplified to the extent that it could become
a more generic writeback interface that requires of the XML "payload" only
that the entities to be created/edited/deleted have ids in their XML
representation, and that writeback requests/responses can inject "old_id"
and "delete" attributes/elements into those XML representations.  If we go
in that direction then I think DAS2 writeback could evolve into a more
general DAS writeback that could be used for DAS2, DAS1.53, and probably
many of the DAS extensions.

I'll try to write up a more specific proposal on this over the weekend.

    Gregg

From gregghelt at gmail.com  Wed Oct  1 18:39:20 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 1 Oct 2008 11:39:20 -0700
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
Message-ID: <50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>

Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
temporary teleconference line if the one Ann is setting up isn't ready yet.

      Gregg

On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org> wrote:

> Thursday morning works for me as well.
>
>
> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>
>  I'm free most thursday after 12 noon eastern time, so that works for me.
>>
>> Lincoln
>>
>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com> wrote:
>>
>>  Hello again everybody!
>>>
>>> After taking an eight month sabbatical, I'm back to work (currently as a
>>> free agent).  In the last two months I've focused mainly on distributed
>>> annotation and DAS/2 in particular.  And although traffic on the list has
>>> been light/nonexistent, I know there are a number of others now actively
>>> working on DAS/2 servers and clients.  I'm hoping we can move the offline
>>> discussions we've been having back onto the list.
>>>
>>> I would also like to restart the DAS/2 teleconferences as soon as
>>> possible.
>>> Ann, is the offer to host these on your teleconference line still good?
>>> Would people be up for this Thursday morning (Pacific time) for the first
>>> one?  If not please propose a different time.  I think we should plan to
>>> devote most of the teleconference to a specific topic each time.  For the
>>> first one I'd like to do an overview of the current state of DAS/2 --
>>> spec,
>>> client/server/validator/registry implementations, deployments, who's
>>> working
>>> on what, etc.  After that here's my shortlist, please chime in with other
>>> possibilities:
>>>
>>>   Proposed spec changes -- DAS/2.1
>>>   Integration of DAS1 and DAS/2
>>>   Security / Authorization issues
>>>   Server implementations (Genometry, Biopackages, HapMap, Trellis (my new
>>> stuff))
>>>   Client implementations (IGB, ???)
>>>   Current state of distributed annotation in general
>>>   Integration of DAS/2 with GMOD
>>>
>>> Hope to talk with everyone soon,
>>> Gregg
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>
>>
>>
>> --
>> Lincoln D. Stein
>>
>> Ontario Institute for Cancer Research
>> 101 College St., Suite 800
>> Toronto, ON, Canada M5G0A3
>> 416 673-8514
>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>
>> Cold Spring Harbor Laboratory
>> 1 Bungtown Road
>> Cold Spring Harbor, NY 11724 USA
>> (516) 367-8380
>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>


From suzi at berkeleybop.org  Wed Oct  1 20:14:22 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 1 Oct 2008 14:14:22 -0600
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
Message-ID: <B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>

9am works for me

On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:

> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
> temporary teleconference line if the one Ann is setting up isn't  
> ready yet.
>
>      Gregg
>
> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis  
> <suzi at berkeleybop.org> wrote:
>
>> Thursday morning works for me as well.
>>
>>
>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>
>> I'm free most thursday after 12 noon eastern time, so that works  
>> for me.
>>>
>>> Lincoln
>>>
>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>  
>>> wrote:
>>>
>>> Hello again everybody!
>>>>
>>>> After taking an eight month sabbatical, I'm back to work  
>>>> (currently as a
>>>> free agent).  In the last two months I've focused mainly on  
>>>> distributed
>>>> annotation and DAS/2 in particular.  And although traffic on the  
>>>> list has
>>>> been light/nonexistent, I know there are a number of others now  
>>>> actively
>>>> working on DAS/2 servers and clients.  I'm hoping we can move the  
>>>> offline
>>>> discussions we've been having back onto the list.
>>>>
>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>> possible.
>>>> Ann, is the offer to host these on your teleconference line still  
>>>> good?
>>>> Would people be up for this Thursday morning (Pacific time) for  
>>>> the first
>>>> one?  If not please propose a different time.  I think we should  
>>>> plan to
>>>> devote most of the teleconference to a specific topic each time.   
>>>> For the
>>>> first one I'd like to do an overview of the current state of DAS/ 
>>>> 2 --
>>>> spec,
>>>> client/server/validator/registry implementations, deployments,  
>>>> who's
>>>> working
>>>> on what, etc.  After that here's my shortlist, please chime in  
>>>> with other
>>>> possibilities:
>>>>
>>>>  Proposed spec changes -- DAS/2.1
>>>>  Integration of DAS1 and DAS/2
>>>>  Security / Authorization issues
>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis  
>>>> (my new
>>>> stuff))
>>>>  Client implementations (IGB, ???)
>>>>  Current state of distributed annotation in general
>>>>  Integration of DAS/2 with GMOD
>>>>
>>>> Hope to talk with everyone soon,
>>>> Gregg
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
>>>
>>>
>>> --
>>> Lincoln D. Stein
>>>
>>> Ontario Institute for Cancer Research
>>> 101 College St., Suite 800
>>> Toronto, ON, Canada M5G0A3
>>> 416 673-8514
>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>
>>> Cold Spring Harbor Laboratory
>>> 1 Bungtown Road
>>> Cold Spring Harbor, NY 11724 USA
>>> (516) 367-8380
>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From aloraine at gmail.com  Wed Oct  1 20:26:31 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 1 Oct 2008 16:26:31 -0400
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
Message-ID: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>

Thank you Suzi. Let's use yours if it is not too much trouble.

The time got a little away from me and I haven't had a chance yet to
set up the line on our end.

9 am PST Thursday would be fine.

Best,

Ann

On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
> 9am works for me
>
> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>
>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
>> temporary teleconference line if the one Ann is setting up isn't ready
>> yet.
>>
>>     Gregg
>>
>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
>> wrote:
>>
>>> Thursday morning works for me as well.
>>>
>>>
>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>
>>> I'm free most thursday after 12 noon eastern time, so that works for me.
>>>>
>>>> Lincoln
>>>>
>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com> wrote:
>>>>
>>>> Hello again everybody!
>>>>>
>>>>> After taking an eight month sabbatical, I'm back to work (currently as
>>>>> a
>>>>> free agent).  In the last two months I've focused mainly on distributed
>>>>> annotation and DAS/2 in particular.  And although traffic on the list
>>>>> has
>>>>> been light/nonexistent, I know there are a number of others now
>>>>> actively
>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>> offline
>>>>> discussions we've been having back onto the list.
>>>>>
>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>> possible.
>>>>> Ann, is the offer to host these on your teleconference line still good?
>>>>> Would people be up for this Thursday morning (Pacific time) for the
>>>>> first
>>>>> one?  If not please propose a different time.  I think we should plan
>>>>> to
>>>>> devote most of the teleconference to a specific topic each time.  For
>>>>> the
>>>>> first one I'd like to do an overview of the current state of DAS/2 --
>>>>> spec,
>>>>> client/server/validator/registry implementations, deployments, who's
>>>>> working
>>>>> on what, etc.  After that here's my shortlist, please chime in with
>>>>> other
>>>>> possibilities:
>>>>>
>>>>>  Proposed spec changes -- DAS/2.1
>>>>>  Integration of DAS1 and DAS/2
>>>>>  Security / Authorization issues
>>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
>>>>> new
>>>>> stuff))
>>>>>  Client implementations (IGB, ???)
>>>>>  Current state of distributed annotation in general
>>>>>  Integration of DAS/2 with GMOD
>>>>>
>>>>> Hope to talk with everyone soon,
>>>>> Gregg
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Lincoln D. Stein
>>>>
>>>> Ontario Institute for Cancer Research
>>>> 101 College St., Suite 800
>>>> Toronto, ON, Canada M5G0A3
>>>> 416 673-8514
>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>
>>>> Cold Spring Harbor Laboratory
>>>> 1 Bungtown Road
>>>> Cold Spring Harbor, NY 11724 USA
>>>> (516) 367-8380
>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From suzi at berkeleybop.org  Thu Oct  2 02:49:51 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 1 Oct 2008 20:49:51 -0600
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
	<83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
Message-ID: <4B514BC9-4F5B-4439-A228-0DBD2400E3CE@berkeleybop.org>

Okey-doke.

Here is the call in information, at least for tomorrow.

866-692-3582 4977624#

I don't know for certain how this works from the UK. If it pertains  
I'll dig deeper and find out, just speak up and let me know.

Talk to you all in the morn.

-S

On Oct 1, 2008, at 2:26 PM, Ann Loraine wrote:

> Thank you Suzi. Let's use yours if it is not too much trouble.
>
> The time got a little away from me and I haven't had a chance yet to
> set up the line on our end.
>
> 9 am PST Thursday would be fine.
>
> Best,
>
> Ann
>
> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>  
> wrote:
>> 9am works for me
>>
>> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>>
>>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set  
>>> up a
>>> temporary teleconference line if the one Ann is setting up isn't  
>>> ready
>>> yet.
>>>
>>>    Gregg
>>>
>>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis  
>>> <suzi at berkeleybop.org>
>>> wrote:
>>>
>>>> Thursday morning works for me as well.
>>>>
>>>>
>>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>>
>>>> I'm free most thursday after 12 noon eastern time, so that works  
>>>> for me.
>>>>>
>>>>> Lincoln
>>>>>
>>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt  
>>>>> <gregghelt at gmail.com> wrote:
>>>>>
>>>>> Hello again everybody!
>>>>>>
>>>>>> After taking an eight month sabbatical, I'm back to work  
>>>>>> (currently as
>>>>>> a
>>>>>> free agent).  In the last two months I've focused mainly on  
>>>>>> distributed
>>>>>> annotation and DAS/2 in particular.  And although traffic on  
>>>>>> the list
>>>>>> has
>>>>>> been light/nonexistent, I know there are a number of others now
>>>>>> actively
>>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>>> offline
>>>>>> discussions we've been having back onto the list.
>>>>>>
>>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>>> possible.
>>>>>> Ann, is the offer to host these on your teleconference line  
>>>>>> still good?
>>>>>> Would people be up for this Thursday morning (Pacific time) for  
>>>>>> the
>>>>>> first
>>>>>> one?  If not please propose a different time.  I think we  
>>>>>> should plan
>>>>>> to
>>>>>> devote most of the teleconference to a specific topic each  
>>>>>> time.  For
>>>>>> the
>>>>>> first one I'd like to do an overview of the current state of  
>>>>>> DAS/2 --
>>>>>> spec,
>>>>>> client/server/validator/registry implementations, deployments,  
>>>>>> who's
>>>>>> working
>>>>>> on what, etc.  After that here's my shortlist, please chime in  
>>>>>> with
>>>>>> other
>>>>>> possibilities:
>>>>>>
>>>>>> Proposed spec changes -- DAS/2.1
>>>>>> Integration of DAS1 and DAS/2
>>>>>> Security / Authorization issues
>>>>>> Server implementations (Genometry, Biopackages, HapMap, Trellis  
>>>>>> (my
>>>>>> new
>>>>>> stuff))
>>>>>> Client implementations (IGB, ???)
>>>>>> Current state of distributed annotation in general
>>>>>> Integration of DAS/2 with GMOD
>>>>>>
>>>>>> Hope to talk with everyone soon,
>>>>>> Gregg
>>>>>> _______________________________________________
>>>>>> DAS2 mailing list
>>>>>> DAS2 at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lincoln D. Stein
>>>>>
>>>>> Ontario Institute for Cancer Research
>>>>> 101 College St., Suite 800
>>>>> Toronto, ON, Canada M5G0A3
>>>>> 416 673-8514
>>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>>
>>>>> Cold Spring Harbor Laboratory
>>>>> 1 Bungtown Road
>>>>> Cold Spring Harbor, NY 11724 USA
>>>>> (516) 367-8380
>>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From lincoln.stein at gmail.com  Thu Oct  2 03:50:33 2008
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Wed, 1 Oct 2008 23:50:33 -0400
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
References: <50158cb00809291427o43de54b7ra26c2ca6fc63fbb1@mail.gmail.com>
	<6dce9a0b0809300900o411fcd38n3bdda34fe775fe4e@mail.gmail.com>
	<DCFEBE08-D0FD-445C-A586-0CCAC6A11C5F@berkeleybop.org>
	<50158cb00810011139h1d11ff0dp37e40d4dcda71144@mail.gmail.com>
	<B74BACEB-DA51-485C-92F4-7D2199D1EA60@berkeleybop.org>
	<83722dde0810011326k65ca432ck33a85e46e02de871@mail.gmail.com>
Message-ID: <6dce9a0b0810012050l553ff7c2h24c175cceb37ab1b@mail.gmail.com>

Hi,

This will not work for me this week (tomorrow) because of a conflicting
conference call. Other weeks will be fine.

Lincoln

On Wed, Oct 1, 2008 at 4:26 PM, Ann Loraine <aloraine at gmail.com> wrote:

> Thank you Suzi. Let's use yours if it is not too much trouble.
>
> The time got a little away from me and I haven't had a chance yet to
> set up the line on our end.
>
> 9 am PST Thursday would be fine.
>
> Best,
>
> Ann
>
> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>
> wrote:
> > 9am works for me
> >
> > On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
> >
> >> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
> >> temporary teleconference line if the one Ann is setting up isn't ready
> >> yet.
> >>
> >>     Gregg
> >>
> >> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
> >> wrote:
> >>
> >>> Thursday morning works for me as well.
> >>>
> >>>
> >>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
> >>>
> >>> I'm free most thursday after 12 noon eastern time, so that works for
> me.
> >>>>
> >>>> Lincoln
> >>>>
> >>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>
> wrote:
> >>>>
> >>>> Hello again everybody!
> >>>>>
> >>>>> After taking an eight month sabbatical, I'm back to work (currently
> as
> >>>>> a
> >>>>> free agent).  In the last two months I've focused mainly on
> distributed
> >>>>> annotation and DAS/2 in particular.  And although traffic on the list
> >>>>> has
> >>>>> been light/nonexistent, I know there are a number of others now
> >>>>> actively
> >>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
> >>>>> offline
> >>>>> discussions we've been having back onto the list.
> >>>>>
> >>>>> I would also like to restart the DAS/2 teleconferences as soon as
> >>>>> possible.
> >>>>> Ann, is the offer to host these on your teleconference line still
> good?
> >>>>> Would people be up for this Thursday morning (Pacific time) for the
> >>>>> first
> >>>>> one?  If not please propose a different time.  I think we should plan
> >>>>> to
> >>>>> devote most of the teleconference to a specific topic each time.  For
> >>>>> the
> >>>>> first one I'd like to do an overview of the current state of DAS/2 --
> >>>>> spec,
> >>>>> client/server/validator/registry implementations, deployments, who's
> >>>>> working
> >>>>> on what, etc.  After that here's my shortlist, please chime in with
> >>>>> other
> >>>>> possibilities:
> >>>>>
> >>>>>  Proposed spec changes -- DAS/2.1
> >>>>>  Integration of DAS1 and DAS/2
> >>>>>  Security / Authorization issues
> >>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
> >>>>> new
> >>>>> stuff))
> >>>>>  Client implementations (IGB, ???)
> >>>>>  Current state of distributed annotation in general
> >>>>>  Integration of DAS/2 with GMOD
> >>>>>
> >>>>> Hope to talk with everyone soon,
> >>>>> Gregg
> >>>>> _______________________________________________
> >>>>> DAS2 mailing list
> >>>>> DAS2 at lists.open-bio.org
> >>>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Lincoln D. Stein
> >>>>
> >>>> Ontario Institute for Cancer Research
> >>>> 101 College St., Suite 800
> >>>> Toronto, ON, Canada M5G0A3
> >>>> 416 673-8514
> >>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
> >>>>
> >>>> Cold Spring Harbor Laboratory
> >>>> 1 Bungtown Road
> >>>> Cold Spring Harbor, NY 11724 USA
> >>>> (516) 367-8380
> >>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
> >>>> _______________________________________________
> >>>> DAS2 mailing list
> >>>> DAS2 at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>
> >>>>
> >>>
> >> _______________________________________________
> >> DAS2 mailing list
> >> DAS2 at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/das2
> >>
> >
> > _______________________________________________
> > DAS2 mailing list
> > DAS2 at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/das2
> >
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



-- 
Lincoln D. Stein

Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>

Cold Spring Harbor Laboratory
1 Bungtown Road
Cold Spring Harbor, NY 11724 USA
(516) 367-8380
Assistant: Sandra Michelsen <michelse at cshl.edu>


From gregghelt at gmail.com  Thu Oct  2 12:57:40 2008
From: gregghelt at gmail.com (gregghelt at gmail.com)
Date: Thu, 02 Oct 2008 05:57:40 -0700
Subject: [DAS2] DAS/2 Grant Final Progress Report (submitted August 2008)
Message-ID: <0015175cde880f6df3045844c3c0@google.com>

For today's DAS/2 teleconference I'd like to focus on an overview of the  
current state of DAS/2. So for reference I've attached below the final  
progress report that I submitted for the NIH DAS/2 grant (with minor  
edits). Gregg


From gregghelt at gmail.com  Thu Oct  2 13:38:36 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 2 Oct 2008 06:38:36 -0700
Subject: [DAS2] DAS/2 Grant Final Progress Report (submitted August 2008)
In-Reply-To: <0015175cde880f6df3045844c3c0@google.com>
References: <0015175cde880f6df3045844c3c0@google.com>
Message-ID: <50158cb00810020638r534d865cr59331294631b5b09@mail.gmail.com>

Some people aren't seeing the HTML-ized text of the report, which should be
appended at the end of that last email.  So here's it is again attached as a
.doc file.

        Gregg

On Thu, Oct 2, 2008 at 5:57 AM, gregghelt at gmail.com <gregghelt at gmail.com>wrote:

>
> For today's DAS/2 teleconference I'd like to focus on an overview of the
> current state of DAS/2. So for reference I've attached below the final
> progress report that I submitted for the NIH DAS/2 grant (with minor edits).
>
> Gregg
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DAS_2_Final_Progress_Report_Aug_2008_revised.doc
Type: application/msword
Size: 130048 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/das2/attachments/20081002/e442682f/attachment-0001.doc>

From Steve_Chervitz at affymetrix.com  Thu Oct  2 17:39:19 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 02 Oct 2008 10:39:19 -0700
Subject: [DAS2] Restarting DAS/2 teleconferences?
In-Reply-To: <6dce9a0b0810012050l553ff7c2h24c175cceb37ab1b@mail.gmail.com>
Message-ID: <C50A5557.3242A%Steve_Chervitz@affymetrix.com>

This time will normally work for me, and I can post meeting notes, as I have
done in the past, though not for today's call (sorry to miss out).

How frequent should these meetings be? Maybe weekly would be best during
this rev-up period, then transition to monthly after things stabilize?

If someone could post any notes from the meeting, that would be great.

Steve


> From: Lincoln Stein <lincoln.stein at gmail.com>
> Date: Wed, 1 Oct 2008 23:50:33 -0400
> To: Ann Loraine <aloraine at gmail.com>
> Cc: <das2 at lists.open-bio.org>
> Subject: Re: [DAS2] Restarting DAS/2 teleconferences?
> 
> Hi,
> 
> This will not work for me this week (tomorrow) because of a conflicting
> conference call. Other weeks will be fine.
> 
> Lincoln
> 
> On Wed, Oct 1, 2008 at 4:26 PM, Ann Loraine <aloraine at gmail.com> wrote:
> 
>> Thank you Suzi. Let's use yours if it is not too much trouble.
>> 
>> The time got a little away from me and I haven't had a chance yet to
>> set up the line on our end.
>> 
>> 9 am PST Thursday would be fine.
>> 
>> Best,
>> 
>> Ann
>> 
>> On Wed, Oct 1, 2008 at 4:14 PM, Suzanna Lewis <suzi at berkeleybop.org>
>> wrote:
>>> 9am works for me
>>> 
>>> On Oct 1, 2008, at 12:39 PM, Gregg Helt wrote:
>>> 
>>>> Okay, how about 9 AM Pacific time tomorrow (Thursday)?  I can set up a
>>>> temporary teleconference line if the one Ann is setting up isn't ready
>>>> yet.
>>>> 
>>>>     Gregg
>>>> 
>>>> On Tue, Sep 30, 2008 at 9:15 AM, Suzanna Lewis <suzi at berkeleybop.org>
>>>> wrote:
>>>> 
>>>>> Thursday morning works for me as well.
>>>>> 
>>>>> 
>>>>> On Sep 30, 2008, at 10:00 AM, Lincoln Stein wrote:
>>>>> 
>>>>> I'm free most thursday after 12 noon eastern time, so that works for
>> me.
>>>>>> 
>>>>>> Lincoln
>>>>>> 
>>>>>> On Mon, Sep 29, 2008 at 5:27 PM, Gregg Helt <gregghelt at gmail.com>
>> wrote:
>>>>>> 
>>>>>> Hello again everybody!
>>>>>>> 
>>>>>>> After taking an eight month sabbatical, I'm back to work (currently
>> as
>>>>>>> a
>>>>>>> free agent).  In the last two months I've focused mainly on
>> distributed
>>>>>>> annotation and DAS/2 in particular.  And although traffic on the list
>>>>>>> has
>>>>>>> been light/nonexistent, I know there are a number of others now
>>>>>>> actively
>>>>>>> working on DAS/2 servers and clients.  I'm hoping we can move the
>>>>>>> offline
>>>>>>> discussions we've been having back onto the list.
>>>>>>> 
>>>>>>> I would also like to restart the DAS/2 teleconferences as soon as
>>>>>>> possible.
>>>>>>> Ann, is the offer to host these on your teleconference line still
>> good?
>>>>>>> Would people be up for this Thursday morning (Pacific time) for the
>>>>>>> first
>>>>>>> one?  If not please propose a different time.  I think we should plan
>>>>>>> to
>>>>>>> devote most of the teleconference to a specific topic each time.  For
>>>>>>> the
>>>>>>> first one I'd like to do an overview of the current state of DAS/2 --
>>>>>>> spec,
>>>>>>> client/server/validator/registry implementations, deployments, who's
>>>>>>> working
>>>>>>> on what, etc.  After that here's my shortlist, please chime in with
>>>>>>> other
>>>>>>> possibilities:
>>>>>>> 
>>>>>>>  Proposed spec changes -- DAS/2.1
>>>>>>>  Integration of DAS1 and DAS/2
>>>>>>>  Security / Authorization issues
>>>>>>>  Server implementations (Genometry, Biopackages, HapMap, Trellis (my
>>>>>>> new
>>>>>>> stuff))
>>>>>>>  Client implementations (IGB, ???)
>>>>>>>  Current state of distributed annotation in general
>>>>>>>  Integration of DAS/2 with GMOD
>>>>>>> 
>>>>>>> Hope to talk with everyone soon,
>>>>>>> Gregg
>>>>>>> _______________________________________________
>>>>>>> DAS2 mailing list
>>>>>>> DAS2 at lists.open-bio.org
>>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Lincoln D. Stein
>>>>>> 
>>>>>> Ontario Institute for Cancer Research
>>>>>> 101 College St., Suite 800
>>>>>> Toronto, ON, Canada M5G0A3
>>>>>> 416 673-8514
>>>>>> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
>>>>>> 
>>>>>> Cold Spring Harbor Laboratory
>>>>>> 1 Bungtown Road
>>>>>> Cold Spring Harbor, NY 11724 USA
>>>>>> (516) 367-8380
>>>>>> Assistant: Sandra Michelsen <michelse at cshl.edu>
>>>>>> _______________________________________________
>>>>>> DAS2 mailing list
>>>>>> DAS2 at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>> 
>>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>> 
>>> 
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>> 
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>> 
> 
> 
> 
> -- 
> Lincoln D. Stein
> 
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Stacey Quinn <Stacey.Quinn at oicr.on.ca>
> 
> Cold Spring Harbor Laboratory
> 1 Bungtown Road
> Cold Spring Harbor, NY 11724 USA
> (516) 367-8380
> Assistant: Sandra Michelsen <michelse at cshl.edu>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2

------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.


From jw12 at sanger.ac.uk  Wed Oct  8 13:34:59 2008
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 08 Oct 2008 14:34:59 +0100
Subject: [DAS2] DAS workshop 2009
Message-ID: <1223472899.3418.83.camel@deskpro20727.dynamic.sanger.ac.uk>

We are considering running a DAS workshop here at the Sanger in the UK
in 2009 subject to decent demand.

If would be interested in attending either to present or just take part
then please email me jw12 at sanger.ac.uk

For further details please see the news items section at the top of
www.dasregistry.org

Thanks

Jonathan.



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 


From John.Nicol at uncc.edu  Tue Oct 14 18:36:54 2008
From: John.Nicol at uncc.edu (Nicol, John)
Date: Tue, 14 Oct 2008 14:36:54 -0400
Subject: [DAS2] DAS/2 specification problems
Message-ID: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>

Hi all,

I'm looking at the DAS/2 specification (at, say, http://biodas.org/documents/das2/das2_get.html), and I'm encountering some problems.

Specifically, none of the biodas links appear to work.  These would be useful to do some verifications on our server.
http://www.biodas.org/das/sequence/gallus_gallus/March2004/types
http://www.biodas.org/known_das_servers
http://www.biodas.org/sequence/s.cerevisiae/genes.xml

Many of the other links don't work.  For example:
http://dev.wormbase.org/das/genome/  (which itself links to the unknown http://www.biodas.org/das2)
http://www.ensembl.org/Homo_sapiens/Chr1
http://das.ensembl.org/das/SPICEDS/127/
http://sanger.ac.uk/das-registry/yeast-32-chromosome
http://flybase.org/genome/D_melanogaster/R4.3/dna/X
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4

And here's a typo:
http://ensemble.org/Homo_sapiens/Chr1

Thanks!
John




From andy.jenkinson at ebi.ac.uk  Wed Oct 15 13:28:30 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 15 Oct 2008 14:28:30 +0100
Subject: [DAS2] teleconference
Message-ID: <48F5EFFE.2040901@ebi.ac.uk>

Hi all,

Is there to be another teleconference tomorrow?

Andy


From gregghelt at gmail.com  Wed Oct 15 15:47:46 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 08:47:46 -0700
Subject: [DAS2] teleconference
In-Reply-To: <48F5EFFE.2040901@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
Message-ID: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>

Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?  If
not then Suzi can we use yours again?

Possible topics:
     DAS 1/2/etc. integration
     Security and authorization
     Proposed specification changes

If anyone has a preference for one of the above, or wants to propose another
topic, please post.

       thanks,
       Gregg

On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Hi all,
>
> Is there to be another teleconference tomorrow?
>
> Andy
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From aloraine at gmail.com  Wed Oct 15 15:49:44 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 15 Oct 2008 11:49:44 -0400
Subject: [DAS2] [DAS] teleconference
In-Reply-To: <48F5EFFE.2040901@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
Message-ID: <83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>

Dear all,

During our last conference call, we discussed having a teleconference
every two weeks.

What do you think about instead convening on a more ad hoc basis,
using the list for day-to-day communications?

Sincerely,

Ann

On Wed, Oct 15, 2008 at 9:28 AM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk> wrote:
> Hi all,
>
> Is there to be another teleconference tomorrow?
>
> Andy
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>


From suzi at berkeleybop.org  Wed Oct 15 16:21:04 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 12:21:04 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
Message-ID: <9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>

Gregg I'm on the line if anyone is still available.

On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:

> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set  
> up?  If
> not then Suzi can we use yours again?
>
> Possible topics:
>     DAS 1/2/etc. integration
>     Security and authorization
>     Proposed specification changes
>
> If anyone has a preference for one of the above, or wants to propose  
> another
> topic, please post.
>
>       thanks,
>       Gregg
>
> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> Hi all,
>>
>> Is there to be another teleconference tomorrow?
>>
>> Andy
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From andy.jenkinson at ebi.ac.uk  Wed Oct 15 16:24:11 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 15 Oct 2008 17:24:11 +0100
Subject: [DAS2] teleconference
In-Reply-To: <9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
Message-ID: <48F6192B.5070401@ebi.ac.uk>

This is supposed to be tomorrow (Thursday) right?

Suzanna Lewis wrote:
> Gregg I'm on the line if anyone is still available.
> 
> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
> 
>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set 
>> up?  If
>> not then Suzi can we use yours again?
>>
>> Possible topics:
>>     DAS 1/2/etc. integration
>>     Security and authorization
>>     Proposed specification changes
>>
>> If anyone has a preference for one of the above, or wants to propose 
>> another
>> topic, please post.
>>
>>       thanks,
>>       Gregg
>>
>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson 
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>> Hi all,
>>>
>>> Is there to be another teleconference tomorrow?
>>>
>>> Andy
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>


From jw12 at sanger.ac.uk  Wed Oct 15 16:28:11 2008
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 15 Oct 2008 17:28:11 +0100
Subject: [DAS2] Spec Review
Message-ID: <1224088091.5029.60.camel@deskpro20727.dynamic.sanger.ac.uk>

Further to Andy's email below, we have written a spec review document at
http://www.biodas.org/wiki/Spec_Review, which is still a work in
progress as the DAS spec will probably always be to a degree.

To reiterate, this  document is  "to make the document more consistent
with common usage and add official support for the "sources" metadata
command (from 1.53E and DAS/2) and to reduce complexity and confusion by
removing unused features." It's editable (if you register with the site
and log in). So we encourage people to either edit or make suggestions
via the das email lists.

We have also created another document so we can all propose new
extensions and ways forward to improve the above "consolidated" spec at
http://www.biodas.org/wiki/DAS_Plans

Cheers

Joanthan. 








------------------------------------------------------------

Hi all,

Over the last couple of weeks there have been a few meetings on the
Hinxton campus aimed at exploring options for reconciling the two
versions of the DAS spec. Involved were myself, Gregg Helt, Jonathan
Warren, Felix Kokocinski, Phil Jones, Henning Hermjakob and Tim Hubbard.

As a first step we have conducted a review of the current 1.53 spec with
a view to updating it. The aim is to make the document more consistent
with common usage, add official support for the "sources" metadata
command (from 1.53E and DAS/2) and to reduce complexity and confusion by
removing unused features. Another mail will be sent out soon with the
conclusions so that they can be discussed before any changes are made.

Cheers,
Andy



-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 


From suzi at berkeleybop.org  Wed Oct 15 16:15:02 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 12:15:02 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
Message-ID: <2718D4AE-F29C-4FF3-986D-9F2C4C81C90E@berkeleybop.org>

Gregg, you all must be on the call already (yes, using my line is  
okay), but I'm caught up in the course here and can't make the call  
myself.

-S

On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:

> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set  
> up?  If
> not then Suzi can we use yours again?
>
> Possible topics:
>     DAS 1/2/etc. integration
>     Security and authorization
>     Proposed specification changes
>
> If anyone has a preference for one of the above, or wants to propose  
> another
> topic, please post.
>
>       thanks,
>       Gregg
>
> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> Hi all,
>>
>> Is there to be another teleconference tomorrow?
>>
>> Andy
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From gregghelt at gmail.com  Wed Oct 15 17:12:52 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:12:52 -0700
Subject: [DAS2] teleconference
In-Reply-To: <48F6192B.5070401@ebi.ac.uk>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
	<48F6192B.5070401@ebi.ac.uk>
Message-ID: <50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>

Yes the conference call is tomorrow (Thursday) at 9 AM Pacific time.  Sorry
for any confusion.

      Gregg

On Wed, Oct 15, 2008 at 9:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> This is supposed to be tomorrow (Thursday) right?
>
>
> Suzanna Lewis wrote:
>
>> Gregg I'm on the line if anyone is still available.
>>
>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>
>>  Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>>  If
>>> not then Suzi can we use yours again?
>>>
>>> Possible topics:
>>>    DAS 1/2/etc. integration
>>>    Security and authorization
>>>    Proposed specification changes
>>>
>>> If anyone has a preference for one of the above, or wants to propose
>>> another
>>> topic, please post.
>>>
>>>      thanks,
>>>      Gregg
>>>
>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <
>>> andy.jenkinson at ebi.ac.uk>wrote:
>>>
>>>  Hi all,
>>>>
>>>> Is there to be another teleconference tomorrow?
>>>>
>>>> Andy
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>  _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>>


From gregghelt at gmail.com  Wed Oct 15 17:18:39 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:18:39 -0700
Subject: [DAS2] [DAS] teleconference
In-Reply-To: <83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<83722dde0810150849p3a160548r295b9a7d5b2db162@mail.gmail.com>
Message-ID: <50158cb00810151018x4d342dem71a559e0864f4a04@mail.gmail.com>

I think we really need to have a regularly scheduled teleconference every
two weeks, rather than ad-hoc.  If we focus on one or two topics each
teleconference people who can't attend every time can join in for those
they're most interested in.

      Gregg

On Wed, Oct 15, 2008 at 8:49 AM, Ann Loraine <aloraine at gmail.com> wrote:

> Dear all,
>
> During our last conference call, we discussed having a teleconference
> every two weeks.
>
> What do you think about instead convening on a more ad hoc basis,
> using the list for day-to-day communications?
>
> Sincerely,
>
> Ann
>
> On Wed, Oct 15, 2008 at 9:28 AM, Andy Jenkinson
> <andy.jenkinson at ebi.ac.uk> wrote:
> > Hi all,
> >
> > Is there to be another teleconference tomorrow?
> >
> > Andy
> > _______________________________________________
> > 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
>


From suzi at berkeleybop.org  Wed Oct 15 17:23:33 2008
From: suzi at berkeleybop.org (Suzanna Lewis)
Date: Wed, 15 Oct 2008 13:23:33 -0400
Subject: [DAS2] teleconference
In-Reply-To: <50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>
References: <48F5EFFE.2040901@ebi.ac.uk>
	<50158cb00810150847x72f51b91l461fdbb9945b8907@mail.gmail.com>
	<9F4A9CA4-FF20-47B5-A76E-115FA8506F10@berkeleybop.org>
	<48F6192B.5070401@ebi.ac.uk>
	<50158cb00810151012s7d633925pc5da231d50c920@mail.gmail.com>
Message-ID: <D4C53145-B396-4347-8E8F-83349FAE4A69@berkeleybop.org>

I might be a bit late for tomorrow (wrapping up a lecture), but should  
be able to get on.

Gregg do you have all of the call in information? Or should I send  
this to you again?

-S

On Oct 15, 2008, at 1:12 PM, Gregg Helt wrote:

> Yes the conference call is tomorrow (Thursday) at 9 AM Pacific  
> time.  Sorry
> for any confusion.
>
>      Gregg
>
> On Wed, Oct 15, 2008 at 9:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk 
> >wrote:
>
>> This is supposed to be tomorrow (Thursday) right?
>>
>>
>> Suzanna Lewis wrote:
>>
>>> Gregg I'm on the line if anyone is still available.
>>>
>>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>>
>>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line  
>>> set up?
>>>> If
>>>> not then Suzi can we use yours again?
>>>>
>>>> Possible topics:
>>>>   DAS 1/2/etc. integration
>>>>   Security and authorization
>>>>   Proposed specification changes
>>>>
>>>> If anyone has a preference for one of the above, or wants to  
>>>> propose
>>>> another
>>>> topic, please post.
>>>>
>>>>     thanks,
>>>>     Gregg
>>>>
>>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson <
>>>> andy.jenkinson at ebi.ac.uk>wrote:
>>>>
>>>> Hi all,
>>>>>
>>>>> Is there to be another teleconference tomorrow?
>>>>>
>>>>> Andy
>>>>> _______________________________________________
>>>>> DAS2 mailing list
>>>>> DAS2 at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>>
>>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From aloraine at gmail.com  Wed Oct 15 17:24:31 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Wed, 15 Oct 2008 13:24:31 -0400
Subject: [DAS2] setting up DAS conference, was: Re:  teleconference
Message-ID: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>

Hi all,

I just talked to the telecom support at UNC Charlotte.

I reserved a time for us to use a conference call line
("Meet-me-conf") at the University starting 12 pm EST.

The number everybody would call is: 704-687-8984.

There's a little complication in that somebody on campus will have to
initiate the call for me, but I think I can find somebody to help out
with that aspect.

-Ann


On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
> Gregg, you all must be on the call already (yes, using my line is okay), but
> I'm caught up in the course here and can't make the call myself.
>
> -S
>
> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>
>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>  If
>> not then Suzi can we use yours again?
>>
>> Possible topics:
>>    DAS 1/2/etc. integration
>>    Security and authorization
>>    Proposed specification changes
>>
>> If anyone has a preference for one of the above, or wants to propose
>> another
>> topic, please post.
>>
>>      thanks,
>>      Gregg
>>
>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>> Hi all,
>>>
>>> Is there to be another teleconference tomorrow?
>>>
>>> Andy
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From gregghelt at gmail.com  Wed Oct 15 17:46:37 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 15 Oct 2008 10:46:37 -0700
Subject: [DAS2] DAS/2 specification problems
In-Reply-To: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>
References: <1A3FF4C9782A1249BDFC2FF2B5749C983B152922@EXEVS01.its.uncc.edu>
Message-ID: <50158cb00810151046t1cdcdb95j9cac88d342d465c8@mail.gmail.com>

Apologies, most of the XML responses in the DAS/2 protocol specification are
only examples, not responses from actual servers.  We could change this so
that the spec uses example from working servers.  However, none of the
currently deployed DAS/2 servers that I know of exercise every optional
element and attribute of the spec, so they would be incomplete examples.
But the spec HTML docs are definitely due for an overhaul...

Here's the overview page for the main Affymetrix DAS/2 server, with example
sources, types, segments, and features queries:
    http://netaffxdas.affymetrix.com/das2

Also, at least one of the URLs you list is not guaranteed to be resolvable:
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4
This is given as the value for the uri attribute of a COORDINATES element.
These URIs MAY be resolvable but do not have to be.

In general as part of a spec revision (DAS 2.1?) I'd like to eliminate more
of the resolvability requirements in the specification, and specify that
most URIs be used as identifiers with _optional_ resolvability.  After two
years of working with the current spec I've come to believe that for most
cases requiring URI resolution is not necessary, places added burden on
server implementations, and limits the ability to do non-authoritative
decentralized annotation.

     sincerely,
     Gregg

On Tue, Oct 14, 2008 at 11:36 AM, Nicol, John <John.Nicol at uncc.edu> wrote:

> Hi all,
>
> I'm looking at the DAS/2 specification (at, say,
> http://biodas.org/documents/das2/das2_get.html), and I'm encountering some
> problems.
>
> Specifically, none of the biodas links appear to work.  These would be
> useful to do some verifications on our server.
> http://www.biodas.org/das/sequence/gallus_gallus/March2004/types
> http://www.biodas.org/known_das_servers
> http://www.biodas.org/sequence/s.cerevisiae/genes.xml
>
> Many of the other links don't work.  For example:
> http://dev.wormbase.org/das/genome/  (which itself links to the unknown
> http://www.biodas.org/das2)
> http://www.ensembl.org/Homo_sapiens/Chr1
> http://das.ensembl.org/das/SPICEDS/127/
> http://sanger.ac.uk/das-registry/yeast-32-chromosome
> http://flybase.org/genome/D_melanogaster/R4.3/dna/X
> http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B34.3/dna/chr4
>
> And here's a typo:
> http://ensemble.org/Homo_sapiens/Chr1
>
> Thanks!
> John
>
>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From aloraine at gmail.com  Thu Oct 16 14:04:20 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Thu, 16 Oct 2008 10:04:20 -0400
Subject: [DAS2] setting up DAS conference, was: Re:  teleconference
In-Reply-To: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
References: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
Message-ID: <83722dde0810160704g7adca679m7b80512ae8d59f7f@mail.gmail.com>

Dear all,

The conference call for today is confirmed -- please call:

704-687-8984

at noon, EST (9 am PST)

Best,

Ann

On Wed, Oct 15, 2008 at 1:24 PM, Ann Loraine <aloraine at gmail.com> wrote:
> Hi all,
>
> I just talked to the telecom support at UNC Charlotte.
>
> I reserved a time for us to use a conference call line
> ("Meet-me-conf") at the University starting 12 pm EST.
>
> The number everybody would call is: 704-687-8984.
>
> There's a little complication in that somebody on campus will have to
> initiate the call for me, but I think I can find somebody to help out
> with that aspect.
>
> -Ann
>
>
> On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org> wrote:
>> Gregg, you all must be on the call already (yes, using my line is okay), but
>> I'm caught up in the course here and can't make the call myself.
>>
>> -S
>>
>> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
>>
>>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set up?
>>>  If
>>> not then Suzi can we use yours again?
>>>
>>> Possible topics:
>>>    DAS 1/2/etc. integration
>>>    Security and authorization
>>>    Proposed specification changes
>>>
>>> If anyone has a preference for one of the above, or wants to propose
>>> another
>>> topic, please post.
>>>
>>>      thanks,
>>>      Gregg
>>>
>>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
>>> <andy.jenkinson at ebi.ac.uk>wrote:
>>>
>>>> Hi all,
>>>>
>>>> Is there to be another teleconference tomorrow?
>>>>
>>>> Andy
>>>> _______________________________________________
>>>> DAS2 mailing list
>>>> DAS2 at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>>
>>> _______________________________________________
>>> DAS2 mailing list
>>> DAS2 at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das2
>>>
>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>


From gregghelt at gmail.com  Thu Oct 16 14:37:21 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 16 Oct 2008 07:37:21 -0700
Subject: [DAS2] Fwd: setting up DAS conference, was: Re:  teleconference
In-Reply-To: <50158cb00810160736v208049au70702e57d18f871c@mail.gmail.com>
References: <83722dde0810151024q3a8d366bvc3cdd471daa1ccb3@mail.gmail.com>
	<83722dde0810160704g7adca679m7b80512ae8d59f7f@mail.gmail.com>
	<50158cb00810160736v208049au70702e57d18f871c@mail.gmail.com>
Message-ID: <50158cb00810160737h329a4b91v469fc4d9487397fe@mail.gmail.com>

---------- Forwarded message ----------
From: Gregg Helt <gregghelt at gmail.com>
Date: Thu, Oct 16, 2008 at 7:36 AM
Subject: Re: setting up DAS conference, was: Re: [DAS2] teleconference
To: Ann Loraine <aloraine at gmail.com>


Is there a conference ID that needs to be entered?
Also is there a toll-free number?  An international number?

     thanks!
     Gregg


On Thu, Oct 16, 2008 at 7:04 AM, Ann Loraine <aloraine at gmail.com> wrote:

> Dear all,
>
> The conference call for today is confirmed -- please call:
>
> 704-687-8984
>
> at noon, EST (9 am PST)
>
> Best,
>
> Ann
>
> On Wed, Oct 15, 2008 at 1:24 PM, Ann Loraine <aloraine at gmail.com> wrote:
> > Hi all,
> >
> > I just talked to the telecom support at UNC Charlotte.
> >
> > I reserved a time for us to use a conference call line
> > ("Meet-me-conf") at the University starting 12 pm EST.
> >
> > The number everybody would call is: 704-687-8984.
> >
> > There's a little complication in that somebody on campus will have to
> > initiate the call for me, but I think I can find somebody to help out
> > with that aspect.
> >
> > -Ann
> >
> >
> > On Wed, Oct 15, 2008 at 12:15 PM, Suzanna Lewis <suzi at berkeleybop.org>
> wrote:
> >> Gregg, you all must be on the call already (yes, using my line is okay),
> but
> >> I'm caught up in the course here and can't make the call myself.
> >>
> >> -S
> >>
> >> On Oct 15, 2008, at 11:47 AM, Gregg Helt wrote:
> >>
> >>> Yes, same time, 9 AM Pacific.  Ann do you have a conference line set
> up?
> >>>  If
> >>> not then Suzi can we use yours again?
> >>>
> >>> Possible topics:
> >>>    DAS 1/2/etc. integration
> >>>    Security and authorization
> >>>    Proposed specification changes
> >>>
> >>> If anyone has a preference for one of the above, or wants to propose
> >>> another
> >>> topic, please post.
> >>>
> >>>      thanks,
> >>>      Gregg
> >>>
> >>> On Wed, Oct 15, 2008 at 6:28 AM, Andy Jenkinson
> >>> <andy.jenkinson at ebi.ac.uk>wrote:
> >>>
> >>>> Hi all,
> >>>>
> >>>> Is there to be another teleconference tomorrow?
> >>>>
> >>>> Andy
> >>>> _______________________________________________
> >>>> DAS2 mailing list
> >>>> DAS2 at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>>
> >>> _______________________________________________
> >>> DAS2 mailing list
> >>> DAS2 at lists.open-bio.org
> >>> http://lists.open-bio.org/mailman/listinfo/das2
> >>>
> >>
> >> _______________________________________________
> >> DAS2 mailing list
> >> DAS2 at lists.open-bio.org
> >> http://lists.open-bio.org/mailman/listinfo/das2
> >>
> >
>


From gregghelt at gmail.com  Tue Oct 28 18:02:37 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Tue, 28 Oct 2008 11:02:37 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
Message-ID: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>

I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
framework, and Ivy is the DAS1 proxy plugin.  The source code is available
via SVN at http://code.google.com/p/genomancer/ .  This should definitely be
considered a beta release, there are plenty of features that aren't yet
implemented and I'm sure still some bugs in what is implemented.

I'm hoping a stable version of this can eventually be set up close to or
integrated with the DAS1 registry.  For current testing I've deployed an
instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
hardwired to proxy for the Sanger DAS1
registry<http://www.dasregistry.org/das1/sources>.
Some example DAS2 queries and the DAS1 queries they proxy for:

All DAS1 registry sources:
http://www.dasregistry.org/das1/sources
All DAS1 registry sources --> DAS1+2 sources
http://www.genomancer.org/das2/das1_proxy/sources

DAS1 filtered sources
http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
DAS1 filtered sources --> DAS1+2 filtered sources
http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types

Ensembl DAS1 entry points
http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
Ensembl DAS1 entry points --> DAS2 segments
http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points

Uniprot DAS1 types
http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
Uniprot DAS1 types --> DAS2 types:
http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types

Uniprot DAS1 features (from UniProt DAS home page example)
http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
UniProt DAS1 features --> DAS2 features
http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502

Ensembl DAS1 features (from Ensembl DAS home page example)
http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
Ensembl DAS1 features --> DAS2 features
http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806

UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
request (copied from IGB testing):
http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene


Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
    DAS1 sequence --> DAS2 segments
    DAS1 dsn --> DAS2 sources
    DAS1 stylesheet --> DAS2 stylesheet
I'll post a summary of plans for these queries and other features soon, but
I wanted to at least send out this announcement so people who are interested
can check out the examples.  Please let me know what you think.

    Gregg


From gilmanb at pantherinformatics.com  Tue Oct 28 18:18:05 2008
From: gilmanb at pantherinformatics.com (Brian Gilman)
Date: Tue, 28 Oct 2008 14:18:05 -0400
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
Message-ID: <FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>

Greg,

	Can I use the DAS2 server framework to write the Haploview service?

-B
--
Brian Gilman
President Panther Informatics Inc.
E-Mail: gilmanb at pantherinformatics.com
         gilmanb at jforge.net
AIM: gilmanb1

<a href="www.scilink.com/people/gilmanb"><img src="http://www.scilink.com/images/buttons/scilink_viewmy_black.png 
"/></a>


On Oct 28, 2008, at 2:02 PM, Gregg Helt wrote:

> I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2  
> server
> framework, and Ivy is the DAS1 proxy plugin.  The source code is  
> available
> via SVN at http://code.google.com/p/genomancer/ .  This should  
> definitely be
> considered a beta release, there are plenty of features that aren't  
> yet
> implemented and I'm sure still some bugs in what is implemented.
>
> I'm hoping a stable version of this can eventually be set up close  
> to or
> integrated with the DAS1 registry.  For current testing I've  
> deployed an
> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.   
> It's
> hardwired to proxy for the Sanger DAS1
> registry<http://www.dasregistry.org/das1/sources>.
> Some example DAS2 queries and the DAS1 queries they proxy for:
>
> All DAS1 registry sources:
> http://www.dasregistry.org/das1/sources
> All DAS1 registry sources --> DAS1+2 sources
> http://www.genomancer.org/das2/das1_proxy/sources
>
> DAS1 filtered sources
> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
> DAS1 filtered sources --> DAS1+2 filtered sources
> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>
> Ensembl DAS1 entry points
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
> Ensembl DAS1 entry points --> DAS2 segments
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>
> Uniprot DAS1 types
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
> Uniprot DAS1 types --> DAS2 types:
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>
> Uniprot DAS1 features (from UniProt DAS home page example)
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
> UniProt DAS1 features --> DAS2 features
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>
> Ensembl DAS1 features (from Ensembl DAS home page example)
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
> Ensembl DAS1 features --> DAS2 features
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>
> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
> request (copied from IGB testing):
> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>
>
> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>    DAS1 sequence --> DAS2 segments
>    DAS1 dsn --> DAS2 sources
>    DAS1 stylesheet --> DAS2 stylesheet
> I'll post a summary of plans for these queries and other features  
> soon, but
> I wanted to at least send out this announcement so people who are  
> interested
> can check out the examples.  Please let me know what you think.
>
>    Gregg
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>



From gregghelt at gmail.com  Tue Oct 28 18:58:54 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Tue, 28 Oct 2008 11:58:54 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
	<FF126211-517F-4EF9-96EF-CAA7B9640416@pantherinformatics.com>
Message-ID: <50158cb00810281158h60fe4f0bsdd9b8993c1c2972b@mail.gmail.com>

Yes, I was actually thinking of the HapMap DAS/2 server as one potential
project.  I'd definitely be interested in helping!

In the Trellis source code there's a Trellis DAS/2 data model API in package
genomancer.trellis.das2.model.  These Java interfaces are based on a UML
model -- I'll try to post the UML later today.  Plugins for particular data
backends need to implement the
genomancer.trellis.das2.server.TrellisSourcesPluginI interface, which in
turn relies on the plugin having implementations of the DAS/2 data model.
Trellis is a Java servlet, and you configure Trellis to use a plugin by
setting the TrellisDas2Servlet "sources_plugin_class" init-param, either
programatically or via configuration in the web application deployment
descriptor.

Currently there are two Trellis-based servers in the genomancer source code,
a DAS2-->DAS2 proxy (genomancer.vine.das2.proxy.JettyDas2ProxyServer) and a
DAS1-->DAS2 proxy (genomancer.ivy.das2.proxy.JettyDas1ProxyServer).  Both of
these use Jetty for the HTTP server and servlet container, and have the
plugin hardcoded as well as a hardcoded localhost address and port.  I plan
to have more general examples using Tomcat and standard web app deployment
descriptors by the end of the week.

For my implementations of the Trellis DAS/2 data model, many of the classes
are really data structs with little or no behavior, and just setter/getter
methods.  If you don't want to reimplement the whole data model for these
data-struct classes you should be able to reuse the implementations in the
Vine DAS2 proxy plugin (genomancer.vine.das2.client.modelimpl).  It's the
higher-level parts of the model (particularly the Das2***CapabilityI
interfaces) that will likely need custom implementations for each plugin.

      Gregg

On Tue, Oct 28, 2008 at 11:18 AM, Brian Gilman <
gilmanb at pantherinformatics.com> wrote:

> Greg,
>
>        Can I use the DAS2 server framework to write the Haploview service?
>
> -B
> --
> Brian Gilman
> President Panther Informatics Inc.
> E-Mail: gilmanb at pantherinformatics.com
>        gilmanb at jforge.net
> AIM: gilmanb1
>
> <a href="www.scilink.com/people/gilmanb"><img src="
> http://www.scilink.com/images/buttons/scilink_viewmy_black.png"/></a>
>
>
> On Oct 28, 2008, at 2:02 PM, Gregg Helt wrote:
>
>  I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
>> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
>> framework, and Ivy is the DAS1 proxy plugin.  The source code is available
>> via SVN at http://code.google.com/p/genomancer/ .  This should definitely
>> be
>> considered a beta release, there are plenty of features that aren't yet
>> implemented and I'm sure still some bugs in what is implemented.
>>
>> I'm hoping a stable version of this can eventually be set up close to or
>> integrated with the DAS1 registry.  For current testing I've deployed an
>> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
>> hardwired to proxy for the Sanger DAS1
>> registry<http://www.dasregistry.org/das1/sources>.
>>
>> Some example DAS2 queries and the DAS1 queries they proxy for:
>>
>> All DAS1 registry sources:
>> http://www.dasregistry.org/das1/sources
>> All DAS1 registry sources --> DAS1+2 sources
>> http://www.genomancer.org/das2/das1_proxy/sources
>>
>> DAS1 filtered sources
>> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
>> DAS1 filtered sources --> DAS1+2 filtered sources
>>
>> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>>
>> Ensembl DAS1 entry points
>> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>> Ensembl DAS1 entry points --> DAS2 segments
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>>
>> Uniprot DAS1 types
>> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>> Uniprot DAS1 types --> DAS2 types:
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>>
>> Uniprot DAS1 features (from UniProt DAS home page example)
>> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>> UniProt DAS1 features --> DAS2 features
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>>
>> Ensembl DAS1 features (from Ensembl DAS home page example)
>>
>> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
>> Ensembl DAS1 features --> DAS2 features
>>
>> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>>
>> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
>> request (copied from IGB testing):
>>
>> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>>
>>
>> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>>   DAS1 sequence --> DAS2 segments
>>   DAS1 dsn --> DAS2 sources
>>   DAS1 stylesheet --> DAS2 stylesheet
>> I'll post a summary of plans for these queries and other features soon,
>> but
>> I wanted to at least send out this announcement so people who are
>> interested
>> can check out the examples.  Please let me know what you think.
>>
>>   Gregg
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>


From gregghelt at gmail.com  Wed Oct 29 10:52:07 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 03:52:07 -0700
Subject: [DAS2] Trellis/Ivy: DAS1 --> DAS2 transformational proxy
In-Reply-To: <50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
References: <50158cb00810281043yeb86aa2le133ba79ca522993@mail.gmail.com>
	<50158cb00810281102j2ec9f74au67890874ce38a849@mail.gmail.com>
Message-ID: <50158cb00810290352j1e33877bl623593fb84c17dfb@mail.gmail.com>

If anyone wants to test the DAS1 --> DAS2 transformational proxy with a
DAS/2 client, you can try it with the Integrated Genome Browser
(IGB)<http://www.affymetrix.com/partners_programs/programs/developer/tools/download_igb.affx>by
adding this line to your igb_prefs.xml file (usually located in your
home
directory):

<das2_server name="Trellis/Ivy DAS1 proxy" url="
http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types"
/>

Note that this server will show up in the "Data Access" tab for the current
genome and the "Pick Genome" button for genome selection along with other
DAS/2 servers, instead of in the "Access DAS1 Servers" menu item.

There are a few caveats.

IGB assumes that a DAS2 server provides "features", "segments", and "types"
capabilities for all the sources/versions it serves up.  But there are lots
of DAS servers in the registry that don't have a straightforward way for the
proxy to transform and provide all three capabilities.  To try and minimize
the number of sources IGB will have trouble with, the sources query above
includes filters to restrict the response to a (transformed) subset of the
sources listed in the registry that are likely to meet this requirement.
But there's currently no way to filter for exactly what is wanted (multiple
"capability" filters are OR'd together, not ANDed), so be warned that there
may still be some sources in the response that IGB can't deal with.

The other major caveat is that in order to compare annotations transformed
via the DAS1 proxy server alongside annotations from other DAS/2 servers,
IGB needs to be able to tell that they are using the same coordinate system
(genome assembly).  Currently the DAS1 registry and DAS/2 use different
identifiers for the same genome assembly.  Hopefully they can start using
the same identifiers soon, so I didn't really want to add a short-term (and
brittle) complete id mapping strategy in the proxy.  Until DAS1 and DAS/2
use the same coordinate identifiers the mapping at least for IGB can be done
in IGB, but to do this for the main Affymetrix IGB web start deployment
requires modification on the NetAffx Affymetrix web site (Steve, forgot to
talk to you about this yesterday -- I'll send you details).  So to test for
the next day or two I've done a single hardwired coordinates ID mapping in
the proxy for the latest human genome assembly (NCBIv36).  If you stick to
this genome in IGB you should be able to overlay data from the Trellis/Ivy
DAS1 proxy and other DAS2 servers.

Also keep in mind that none of the performance optimizations that the
Affymetrix Genometry DAS/2 server uses are implemented yet in the
Trellis/Ivy proxy.  So it's best to try out the proxy on small regions of
the genome.

Please let me know if you try this out how it works, any bugs you find, etc.

       Gregg

On Tue, Oct 28, 2008 at 11:02 AM, Gregg Helt <gregghelt at gmail.com> wrote:

> I'm pleased to announce I've got a DAS1 to DAS2 transformational proxy
> working.  I'm calling it Trellis/Ivy.  Trellis is the overall DAS2 server
> framework, and Ivy is the DAS1 proxy plugin.  The source code is available
> via SVN at http://code.google.com/p/genomancer/ .  This should definitely
> be considered a beta release, there are plenty of features that aren't yet
> implemented and I'm sure still some bugs in what is implemented.
>
> I'm hoping a stable version of this can eventually be set up close to or
> integrated with the DAS1 registry.  For current testing I've deployed an
> instance of Trellis/Ivy at genomancer.org in the Amazon EC2 cloud.  It's
> hardwired to proxy for the Sanger DAS1 registry<http://www.dasregistry.org/das1/sources>.
> Some example DAS2 queries and the DAS1 queries they proxy for:
>
> All DAS1 registry sources:
> http://www.dasregistry.org/das1/sources
> All DAS1 registry sources --> DAS1+2 sources
> http://www.genomancer.org/das2/das1_proxy/sources
>
> DAS1 filtered sources
> http://www.dasregistry.org/das1/sources?type=Chromosome&capability=types
> DAS1 filtered sources --> DAS1+2 filtered sources
>
> http://www.genomancer.org/das2/das1_proxy/sources?type=Chromosome&capability=types
>
> Ensembl DAS1 entry points
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
> Ensembl DAS1 entry points --> DAS2 segments
>
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.reference/entry_points
>
> Uniprot DAS1 types
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
> Uniprot DAS1 types --> DAS2 types:
>
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/types
>
> Uniprot DAS1 features (from UniProt DAS home page example)
> http://www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
> UniProt DAS1 features --> DAS2 features
>
> http://www.genomancer.org/das2/das1_proxy/www.ebi.ac.uk/das-srv/uniprot/das/uniprot/features?segment=O35502
>
> Ensembl DAS1 features (from Ensembl DAS home page example)
>
> http://www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13:31787617,31871806
> Ensembl DAS1 features --> DAS2 features
>
> http://www.genomancer.org/das2/das1_proxy/www.ensembl.org/das/Homo_sapiens.NCBI36.transcript/features?segment=13;overlaps=31787616:31871806
>
> UCSC-Gencode segment/overlap/type-filtered, URL-encoded, DAS2 feature
> request (copied from IGB testing):
>
> http://www.genomancer.org/das2/das1_proxy/hgwdev-gencode.cse.ucsc.edu/cgi-bin/das/hg18/features?segment=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2F21;overlaps=26014828%3A26071595;type=http%3A%2F%2Fwww.genomancer.org%2Fdas2%2Fdas1_proxy%2Fhgwdev-gencode.cse.ucsc.edu%2Fcgi-bin%2Fdas%2Fhg18%2FknownGene
>
>
> Basic DAS1.53 query --> DAS2.0 conversions not yet implemented:
>     DAS1 sequence --> DAS2 segments
>     DAS1 dsn --> DAS2 sources
>     DAS1 stylesheet --> DAS2 stylesheet
> I'll post a summary of plans for these queries and other features soon, but
> I wanted to at least send out this announcement so people who are interested
> can check out the examples.  Please let me know what you think.
>
>     Gregg
>
>
>
>


From gregghelt at gmail.com  Wed Oct 29 17:44:08 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 10:44:08 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <49087FF9.5080704@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
Message-ID: <50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>

Using the DAS/2.0 specification, this idea of "annotations of annotations"
is easy to do.  That's because every feature in DAS/2.0 has a unique URI and
is therefore addressable by _any_ other system that uses URIs -- including
another DAS/2.0 server:

<FEATURE uri="http://somewhere.else/feat123" ... >
     <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue XYZ"
/>
</FEATURE>

Or if you prefer allowing your meta-annotation to have it's own URI:

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

Used in this way DAS/2.0 becomes very RDF-like..

This is not just a happy accident but the result of a central tenet of DAS/2
-- addressability of all important DAS/2 entities outside the local system
via URIs.  The DAS/2 writeback spec is built on top of the DAS/2 retrieval
spec, so if you're fully implementing the writeback spec you should be able
to use this ability to do meta-annotations.

      Gregg

P.S. It's great to see development starting up again on DAS writeback!

On Wed, Oct 29, 2008 at 8:23 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>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
>


From gregghelt at gmail.com  Wed Oct 29 17:57:09 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 10:57:09 -0700
Subject: [DAS2] Crossposting to DAS and DAS/2 mailing lists
Message-ID: <50158cb00810291057t27feb2dm92d51797d8fab030@mail.gmail.com>

Hi everyone, just a reminder that we're in a transition period with folding
the DAS/2 mailing list back into the DAS list.  But it hasn't happened yet.
So please for now crosspost to both lists any posts that are of interest to
both.

     thanks,
     Gregg


From andy.jenkinson at ebi.ac.uk  Wed Oct 29 19:04:39 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 29 Oct 2008 19:04:39 +0000
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
Message-ID: <4908B3C7.5020002@ebi.ac.uk>

The difference between an ID and a URI is not so great, any ID can be a 
URI if we refer to the URN definition. But whether this URI should be 
resolvable (that is, a URL) is a big question. Whilst it is certainly a 
nice thing to be able to do, I'm not convinced of the practicality given 
the relationship between simplicity and adoption of technologies like DAS.

Ignoring the difficulty in making something actually resolvable (which 
can potentially be accomplished for features by just having 
"http://server/das/source/features?feature_id=foo") there is more 
pressure than ever on keeping verbosity low, and I'm not sure if this 
can be accomplished as things are right now when you have different URI 
prefixes in the same document. Gregg, perhaps you can elaborate?

I know you also advocate alternative content negotiation to solve this 
issue - do your alternative formats contain these URIs or do they strip 
them?

Gregg Helt wrote:
> Using the DAS/2.0 specification, this idea of "annotations of 
> annotations" is easy to do.  That's because every feature in DAS/2.0 has 
> a unique URI and is therefore addressable by _any_ other system that 
> uses URIs -- including another DAS/2.0 server:
> 
> <FEATURE uri="http://somewhere.else/feat123" ... >
>      <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue 
> XYZ" />
> </FEATURE>
> 
> Or if you prefer allowing your meta-annotation to have it's own URI:
> 
> <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>
> 
> Used in this way DAS/2.0 becomes very RDF-like..
> 
> This is not just a happy accident but the result of a central tenet of 
> DAS/2 -- addressability of all important DAS/2 entities outside the 
> local system via URIs.  The DAS/2 writeback spec is built on top of the 
> DAS/2 retrieval spec, so if you're fully implementing the writeback spec 
> you should be able to use this ability to do meta-annotations.
> 
>       Gregg
> 
> P.S. It's great to see development starting up again on DAS writeback!
> 
> On Wed, Oct 29, 2008 at 8:23 AM, Andy Jenkinson 
> <andy.jenkinson at ebi.ac.uk <mailto:andy.jenkinson at ebi.ac.uk>> 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
>     <mailto:andy.jenkinson at ebi.ac.uk>>
>     Organisation: European Bioinformatics Institute
>     To: Gustavo Salazar <gustavo at nbn.ac.za <mailto:gustavo at nbn.ac.za>>
>     References: <49058C89.7050301 at nbn.ac.za
>     <mailto: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 <mailto:DAS at lists.open-bio.org>
>         http://lists.open-bio.org/mailman/listinfo/das
> 
> 
>     _______________________________________________
>     DAS mailing list
>     DAS at lists.open-bio.org <mailto:DAS at lists.open-bio.org>
>     http://lists.open-bio.org/mailman/listinfo/das
> 
> 


From gregghelt at gmail.com  Wed Oct 29 20:20:47 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 13:20:47 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4908B3C7.5020002@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
	<4908B3C7.5020002@ebi.ac.uk>
Message-ID: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>

Sorry for being imprecise about URIs, what I meant to say was that every
feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
relative URIs but not absolute URIs, and referring to relative URIs is not
particularly useful outside their context.

Furthermore technically not all arbitrary ID strings can actually be
relative URIs either.  I thought this was mostly a theoretical issue until
my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
DAS1 data source I was testing,
http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns features
that derive their IDs from their genomic location, like
"21:26029715,26029814".  Which can't be any form of URI, because according
to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the appearance
of the colon before any forward slash means the "21" should be treated as
the URI scheme, but the scheme can't have a digit as the first character.
This isn't just a rare instance either -- I count at least sixteen data
sources like this (probably more) on ProServer servers for the latest human
genome assembly alone.  On a side note, I'm not sure if these IDs are legal
DAS1.53 feature IDs either, since many of them will not be unique within
their DAS server, and depeding on how you interpret the 1.53 spec the colon
may not be a legal ID character.

The Trellis/Ivy proxy now deals with these cases, but checking each ID to
see if it's a legal URI, and figuring out what to do if it's not, is
definitely adding some performance overhead to the proxy.

This also points to the need for better validation of server responses,
preferably as enhancements to the validation that the DAS1 registry already
does.  I doubt if the current DAS2 validator would catch these kinds of
things either.

I'll chime in with my opinion on the other issues you raise in another
email...

     Gregg

On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk>wrote:

> The difference between an ID and a URI is not so great, any ID can be a URI
> if we refer to the URN definition.


From gregghelt at gmail.com  Wed Oct 29 21:14:46 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 14:14:46 -0700
Subject: [DAS2] Links to old DAS/2 grant and final progress report
Message-ID: <50158cb00810291414u52198f35kd23774b8e538ba87@mail.gmail.com>

I've been reminded recently that when I say stuff like "well in the DAS/2
grant we proposed XYZ" few people can actually look at the old grant and see
what I'm talking about.  So I've posted a copy in a more permanent location:
http://biodas.s3.amazonaws.com/das2grant/DAS2+Grant+Proposal+Feb2003.doc .
I've also posted a copy of the final grant progress report:
http://biodas.s3.amazonaws.com/das2grant/DAS2+Grant+Final+Progress+Report+Aug2008.doc.
 If you do take a look at the grant, keep in mind it was written over
five
years ago.  Back then for example REST was still a relatively new concept,
and SOAP hype was peaking, so there's a fair amount of text dedicated to
explaining the RESTful approach we wanted to take and why we weren't just
using SOAP.  Since then some of the specifics have definitely changed, but I
think the general concepts hold up pretty well.  For instance the current
thread about meta-annotation had me looking back at the section on "Feature
References" and finding it's still relevant.

I've also added links on the BioDAS wiki DAS/2 pages to the grant and
progress report.

      Gregg


From andy.jenkinson at ebi.ac.uk  Wed Oct 29 22:15:08 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 29 Oct 2008 22:15:08 +0000
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	
	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
Message-ID: <4908E06C.3010800@ebi.ac.uk>

Gregg Helt wrote:
> 
> Sorry for being imprecise about URIs, what I meant to say was that every 
> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated 
> as relative URIs but not absolute URIs, and referring to relative URIs 
> is not particularly useful outside their context.

By relative URI do you mean URN (e.g. SO:12345)? As opposed to the HTML 
definition (e.g. index.html). URNs are still useful since they allow us 
to solve this issue of identifying things that are the same. A 
resolvable URI (i.e. a URL) is undoubtedly "better", but this is 
semantic web territory and I'm not convinced it is necessary for DAS. 
Certainly I think it would be too much a constraint to layer onto the 
existing spec in one increment. In fact even using URNs is not easy for 
everything - segment IDs cannot have colons.

> Furthermore technically not all arbitrary ID strings can actually be 
> relative URIs either.  I thought this was mostly a theoretical issue 
> until my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the 
> third DAS1 data source I was testing, 
> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns 
> features that derive their IDs from their genomic location, like 
> "21:26029715,26029814".  Which can't be any form of URI, because 
> according to the URI syntax spec <http://tools.ietf.org/html/rfc3986> 
> the appearance of the colon before any forward slash means the "21" 
> should be treated as the URI scheme, but the scheme can't have a digit 
> as the first character.  This isn't just a rare instance either -- I 
> count at least sixteen data sources like this (probably more) on 
> ProServer servers for the latest human genome assembly alone.

In this case, the ID is the least verbose but still unique-to-the-server 
ID possible, used because the annotation has no natural identifier (the 
source has per-base annotations). Believe me, there are far worse 
implementations - some servers don't even try to generate a unique ID 
for this kind of data. Leaving it blank is something that can be 
rejected in validation, but it's very difficult to verify it's actually 
unique...

There is nothing wrong with this particular example w.r.t the 1.53 spec, 
since the spec says nothing about IDs having to be URIs, it simply says 
they must uniquely identify the feature on the server. But you have hit 
upon one of the reasons _resolvable_ URIs (i.e. URLs) will be difficult 
to implement - annotations that have no natural identifier such as those 
in the batman_CD4 source. Plus, having a unique identifier for every 
base in a genome for every experiment it appears in is always going to 
be verbose.

> On a side 
> note, I'm not sure if these IDs are legal DAS1.53 feature IDs either, 
> since many of them will not be unique within their DAS server, and 
> depeding on how you interpret the 1.53 spec the colon may not be a legal 
> ID character.

I don't think there's a problem with the colon - this is an illegal 
character for reference IDs but not for feature IDs as far as I can see.

> The Trellis/Ivy proxy now deals with these cases, but checking each ID 
> to see if it's a legal URI, and figuring out what to do if it's not, is 
> definitely adding some performance overhead to the proxy.
> 
> This also points to the need for better validation of server responses, 
> preferably as enhancements to the validation that the DAS1 registry 
> already does.  I doubt if the current DAS2 validator would catch these 
> kinds of things either.

If you can give specific examples of things that could be targets for 
validation, I believe Jonathan will add them to his list so he can 
implement them... :)


From garret at globalmentor.com  Wed Oct 29 22:43:17 2008
From: garret at globalmentor.com (Garret Wilson)
Date: Wed, 29 Oct 2008 15:43:17 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
Message-ID: <4908E705.8050904@globalmentor.com>

Forgive me if I seem like I'm splitting hairs a bit here, but it may 
help to clear some of this up.

As RFC 3986 clarifies, there is no such thing as a "relative URI". All 
URIs are "absolute"---i.e. they start with a scheme.

There are, however, "URI references" which may be "URIs" (with a scheme) 
or "relative references". Relative references are a way to take 
advantage of the hierarchical nature of many URIs and store a shortened 
form of the URI in relation to some base URI---but they are not URIs.

The only way to tell if a URI reference is a URI or a relative reference 
is to check for ':', which indicates a URI scheme. Therefore, relative 
references may not have the character ':' within their first path 
segment. But that's not a problem---you can simply prefix the relative 
reference with "./"; thus, the ID "21:26029715,26029814" can easily be 
used as a relative reference in the form "./21:26029715,26029814". 
Again, this is not a URI---to create a URI, you have to resolve this 
relative reference against some base URI.

See RFC 3986 Sections 1.2.3. and 4.1.

Garret

Gregg Helt wrote:
> Sorry for being imprecise about URIs, what I meant to say was that every
> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
> relative URIs but not absolute URIs, and referring to relative URIs is not
> particularly useful outside their context.
>
> Furthermore technically not all arbitrary ID strings can actually be
> relative URIs either.  I thought this was mostly a theoretical issue until
> my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
> DAS1 data source I was testing,
> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns features
> that derive their IDs from their genomic location, like
> "21:26029715,26029814".  Which can't be any form of URI, because according
> to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the appearance
> of the colon before any forward slash means the "21" should be treated as
> the URI scheme, but the scheme can't have a digit as the first character.
> This isn't just a rare instance either -- I count at least sixteen data
> sources like this (probably more) on ProServer servers for the latest human
> genome assembly alone.  On a side note, I'm not sure if these IDs are legal
> DAS1.53 feature IDs either, since many of them will not be unique within
> their DAS server, and depeding on how you interpret the 1.53 spec the colon
> may not be a legal ID character.
>
> The Trellis/Ivy proxy now deals with these cases, but checking each ID to
> see if it's a legal URI, and figuring out what to do if it's not, is
> definitely adding some performance overhead to the proxy.
>
> This also points to the need for better validation of server responses,
> preferably as enhancements to the validation that the DAS1 registry already
> does.  I doubt if the current DAS2 validator would catch these kinds of
> things either.
>
> I'll chime in with my opinion on the other issues you raise in another
> email...
>
>      Gregg
>
> On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
> <andy.jenkinson at ebi.ac.uk>wrote:
>
>   
>> The difference between an ID and a URI is not so great, any ID can be a URI
>> if we refer to the URN definition.
>>     
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>   


From gregghelt at gmail.com  Wed Oct 29 23:39:49 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 16:39:49 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4908E705.8050904@globalmentor.com>
References: <49087FF9.5080704@ebi.ac.uk>
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>
	<4908B3C7.5020002@ebi.ac.uk>
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>
	<4908E705.8050904@globalmentor.com>
Message-ID: <50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>

You're right, I'm still being sloppy about my terminology.

I've used the term "relative URI" as it's specified in the predecessor to
RFC 3986, RFC 2396 <http://www.ietf.org/rfc/rfc2396.txt> .  Apologies, many
of my conversations about the merits of URIs predate the release of RFC 3986
in 2005 -- old habits die hard.  And many specs still use the term "relative
URI".  But I'll try not say "relative URI" any more.  On the other hand, I
_really_ dislike the term "relative reference" because it's so generic, with
no indication of a relation to URIs in the term.  So if it's okay from now
on I'll use the term "relative URI reference" for what I've been calling
"relative URI" and what RFC 3986 calls "relative reference".

Argument via Google for using "relative URI reference":
Search for "relative uri reference" --  9,130 hits, all on first two pages
are relevant
Search for "relative reference" --   272,000 hits, _none_ on first two pages
are relevant, they're either using "relative reference" as a general
computer science term or specifically in relation to Excel.

So let me rephrase.  Every feature in DAS/2.0 has a unique URI.  In the
feature XML this is represented by the "uri" attribute of the FEATURE
element, which is a URI reference (URI or relative URI reference), and
optional xml:base attributes in the document.  DAS/2.0 uses the XML Base
specification <http://www.w3.org/TR/xmlbase/> to resolve relative URI
references via xml:base attributes and/or the URI the document is a
representation of.

So as you suggested, URI references are used in DAS/2.0 to optionally allow
shorthand in the XML for URIs.
Also as you suggested, the Trellis/Ivy DAS1-->DAS2 proxy uses "./" prefixing
to try and make relative URI references out of DAS1 IDs when the ID by
itself is neither a URI nor a relative URI reference.

       So many specs, so little time...
       Gregg

On Wed, Oct 29, 2008 at 3:43 PM, Garret Wilson <garret at globalmentor.com>wrote:

> Forgive me if I seem like I'm splitting hairs a bit here, but it may help
> to clear some of this up.
>
> As RFC 3986 clarifies, there is no such thing as a "relative URI". All URIs
> are "absolute"---i.e. they start with a scheme.
>
> There are, however, "URI references" which may be "URIs" (with a scheme) or
> "relative references". Relative references are a way to take advantage of
> the hierarchical nature of many URIs and store a shortened form of the URI
> in relation to some base URI---but they are not URIs.
>
> The only way to tell if a URI reference is a URI or a relative reference is
> to check for ':', which indicates a URI scheme. Therefore, relative
> references may not have the character ':' within their first path segment.
> But that's not a problem---you can simply prefix the relative reference with
> "./"; thus, the ID "21:26029715,26029814" can easily be used as a relative
> reference in the form "./21:26029715,26029814". Again, this is not a
> URI---to create a URI, you have to resolve this relative reference against
> some base URI.
>
> See RFC 3986 Sections 1.2.3. and 4.1.
>
> Garret
>
> Gregg Helt wrote:
>
>> Sorry for being imprecise about URIs, what I meant to say was that every
>> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated
>> as
>> relative URIs but not absolute URIs, and referring to relative URIs is not
>> particularly useful outside their context.
>>
>> Furthermore technically not all arbitrary ID strings can actually be
>> relative URIs either.  I thought this was mostly a theoretical issue until
>> my Trellis/Ivy DAS1-->DAS2 proxy choked on such a case on only the third
>> DAS1 data source I was testing,
>> http://www.ebi.ac.uk/das-srv/genomicdas/das/batman_CD4.  It returns
>> features
>> that derive their IDs from their genomic location, like
>> "21:26029715,26029814".  Which can't be any form of URI, because according
>> to the URI syntax spec <http://tools.ietf.org/html/rfc3986> the
>> appearance
>> of the colon before any forward slash means the "21" should be treated as
>> the URI scheme, but the scheme can't have a digit as the first character.
>> This isn't just a rare instance either -- I count at least sixteen data
>> sources like this (probably more) on ProServer servers for the latest
>> human
>> genome assembly alone.  On a side note, I'm not sure if these IDs are
>> legal
>> DAS1.53 feature IDs either, since many of them will not be unique within
>> their DAS server, and depeding on how you interpret the 1.53 spec the
>> colon
>> may not be a legal ID character.
>>
>> The Trellis/Ivy proxy now deals with these cases, but checking each ID to
>> see if it's a legal URI, and figuring out what to do if it's not, is
>> definitely adding some performance overhead to the proxy.
>>
>> This also points to the need for better validation of server responses,
>> preferably as enhancements to the validation that the DAS1 registry
>> already
>> does.  I doubt if the current DAS2 validator would catch these kinds of
>> things either.
>>
>> I'll chime in with my opinion on the other issues you raise in another
>> email...
>>
>>     Gregg
>>
>> On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
>> <andy.jenkinson at ebi.ac.uk>wrote:
>>
>>
>>
>>> The difference between an ID and a URI is not so great, any ID can be a
>>> URI
>>> if we refer to the URN definition.
>>>
>>>
>> _______________________________________________
>> DAS2 mailing list
>> DAS2 at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das2
>>
>>
>


From gregghelt at gmail.com  Thu Oct 30 00:29:08 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 17:29:08 -0700
Subject: [DAS2] DAS UML modeling
Message-ID: <50158cb00810291729w4ea8a8fbn755e23d4e2a1db7@mail.gmail.com>

I've committed my latest DAS UML modeling docs into the genomancer source
repository:
     http://genomancer.googlecode.com/svn/trunk/uml/Das.zuml
     http://genomancer.googlecode.com/svn/trunk/uml/Das.xmi

UML modeling of RESTful web services is not a well-defined area -- please
let me know if you have suggestions.  The diagrams in Das.zuml look good in
the Poseidon UML modeler.  Not sure what they'll look like in other apps,
UML diagram rendering standardization efforts still seem iffy.

I've also committed images of some of the diagrams.  Relevant to discussion
of DAS1 to DAS2 comparisons:

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS%20Feature%20Comparison.png

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS%20Feature%20Alignment%20Comparison%20UML.png
These diagrams compare models of DAS1 features, DAS2 features, and DAS1.53E
alignments side-by-side.  I've added some color-coding to highlight
differences that standard UML wouldn't show.  Model fields that are required
attributes/elements in DAS XML are highlighted in red.  References to
elements within the same document are highlighted in green.  References to
elements in other documents are highlighted in purple.

And here's images of the more complete DAS1 and DAS2 models, which have
served as a basis for the Trellis DAS/2 server framework, the Vine DAS/2
proxy plugin, and the Ivy DAS1 proxy plugin:

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS2%20Abstract%20UML.png

http://genomancer.googlecode.com/svn/trunk/uml/images/DAS1%20Abstract%20UML.png

   Gregg


From gregghelt at gmail.com  Thu Oct 30 02:33:26 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 19:33:26 -0700
Subject: [DAS2] using ProServer as a DAS source for IGB
In-Reply-To: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
References: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
Message-ID: <50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>

You're not seeing DAS/2 in IGB because the use of DAS/2 has become an
integral part of IGB, to the point that it's no longer advertised as such.
This was partly motivated by feedback at Affymetrix (internally and from
customers) that DAS1, DAS/2, any mention of these things in IGB was just
confusing to users who didn't know what those were and didnt' really care
what protocol was being used, they just wanted to see the data.

So (unless you've tweaked some advanced prefs) when IGB first launches, goes
to a particular genome assembly, a particular chromosome, and pulls up the
chromosomal banding pattern and RefSeq annotations for that chromosome, all
that is happening via DAS/2.  The "Pick Genome" button that's used to switch
to a different genome assembly uses DAS/2.  The data access panel at the
bottom of IGB that allows you to select other annotation types to load is
using DAS/2.  The tricky bits of ID-to-genome-coordinate resolution that
happen behind the scenes if you load an Affymetrix gene or exon chp file
uses DAS/2.

Now there's a whole separate chunk of code in IGB that enables getting
annotations from DAS1 servers, which is accessed via the File-->"Access
DAS/1 Servers" menu item that you mention.  This is a much older code base,
and for some DAS1 servers it works, but for many others it doesn't.  For
your particular case I'm guessing that the IGB code is ignoring the
X-Das-Capabilities header and assuming that your server supports "types",
"features", and "entry_points" queries (or points to a MapMaster that
supports "entry_points" queries), and it's choking when it turns out the
server doesn't support either "types" or "entry_points".  This is definitely
a bug in IGB, and it didn't get fixed back when the IGB DAS1 client was
being developed because the DAS1 servers that most IGB users were accessing
at the time didn't trigger this bug.

Assuming the problem is with IGB's handling of DAS1 servers, there's several
possible solutions.

1) Configure your DAS server to support all three of the queries the IGB
DAS1 client needs: "types", "features", "entry_points".

2) Trellis/Ivy, the DAS1-->DAS2 proxy I've been developing, might work for
this situation.  Currently it probably won't, as the IGB DAS/2 client also
requires that the DAS/2 data sources support the DAS/2 "types" query.  But
this code base is evolving rapidly, and soon the proxy may be able to inject
type support for DAS1 servers that don't support "types" queries.  It
already does this kind of injection of the DAS/2 "segments" query for many
DAS1 sources in the Sanger DAS1 registry that don't list a
"das1:entry_points" capability.  One caveat to this approach is that
Trellis/Ivy supports the "sources" query but not the "dsn" query, and may
not ever since it looks like "dsn" may soon be deprecated.  Does ProServer
support the 1.53E "sources" query as an alternative to "dsn"?

3) Modify IGB so it can deal with DAS1 servers that don't support "types"
and "entry_points" queries.  But I'm reluctant to dive back into the old IGB
DAS1 code, and I doubt if anyone else wants to either.

4) Modify IGB so it can deal with DAS/2 servers that don't support "types"
and "segments" queries.  This is going to happen eventually, it's just a
question of timing.  Then Trellis/Ivy could be used as-is to proxy for the
DAS1 server and respons to IGB DAS/2 queries.

If it's straightforward to configure the DAS1 server to support "types" and
"entry_points" queries, then that's probably the quickest route.

One other caveat -- in order for IGB to overlay annotations from multiple
data sources, it needs to realize that they're using the same coordinate
system.  If coordinate system IDs don't match exactly, IGB uses a synonym
resolution strategy which usually relies on the synonyms doc at
http://netaffxdas.affymetrix.com/quickload_data/synonyms.txt .  If you can't
overlay annotations from multiple servers it's probably because their
coordinate IDs aren't listed as synonyms.  Let me and/or Steve Trutane know
(steve_chervitz at affymetrix.com) and he can add them in.  Hopefully increased
use of the DAS1 and DAS2 registries will lessen IGB's dependence on synonym
resolution.

      hope that helps,
      Gregg

On Mon, Oct 20, 2008 at 7:24 AM, Hotz, Hans-Rudolf
<hans-rudolf.hotz at fmi.ch>wrote:

> Hi
>
> Your e-mail was given to my by Andy Jenkinson one of the ProServer
> (http://www.sanger.ac.uk/Software/analysis/proserver/) developers at the
> EBI
> in Hinxton, UK).
>
> I am struggling to understand which DAS protocol is used in IGB. All the
> menu tabs are suggesting it is DAS/1 (eg File-> "Access DAS/1 Servers").
> But
> the release notes suggest is DAS/2. And if I try to load data from my
> ProServer I get:
>
>   Error parsing DAS Source
>   org.xml.sax.SAXParseException: Content is not allowed in prolog.
>
>
> Is there a way to use ProServer with IGB?
>
> Thank you very much for your help
>
> Hans
>
>
> Friedrich Miescher Institute
> for Biomedical Research
> Maulbeerstrasse 66
> 4058 Basel/Switzerland
>
>


From Steve_Chervitz at affymetrix.com  Thu Oct 30 02:46:19 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Wed, 29 Oct 2008 19:46:19 -0700
Subject: [DAS2] Minutes from 16 Oct 2008 DAS teleconference
Message-ID: <C52E6E0B.32FE5%Steve_Chervitz@affymetrix.com>

Notes from the biweekly DAS/2 teleconference, 16 Oct 2008

$Id: das2-teleconference-2008-10-16.txt,v 1.1 2008/10/30 02:42:50 sac Exp $

Teleconference Info:
   * Schedule:         Biweekly on Thursday
   * Time of Day:      9:00 AM PDT, 12:00 PM EST, 16:00 GMT
   * Dialin (US):      704-687-8984

Attendees: 
    Free agent: Gregg Helt
    Affymetrix: Steve Chervitz
    EBI: Andy Jenkinson
    Sanger: Jonathan Warren
    U North Carolina: Ann Loraine, Steven Blanchard, John Nicol
    U Utah: David Nix
    LBNL: Suzi Lewis

Note taker: Steve Chervitz

Action items are flagged with '[A]'.

The teleconference schedule and links to past minutes are
available from the Community Portal section of the biodas.org site:
http://www.biodas.org/wiki/BioDAS:Community_Portal#Teleconference

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit on the the discussion list.

========================================================
Agenda: 
* Das1/2 integration
* Security and auth
* Proposed spec changes

Ann: I volunteered to look into getting RCN funding - haven't done
anything on that.

Gregg: Suzy, Me and Ian (Holmes) will submit something in Feb. With
Suzy as the PI. Also, she mentioned that Gmod help desk would get
involved. 

Suzi: This will keep us to 3 institutions, better than 4 -- too
disconnected.

Gregg: combined Sanger, EBI, South Africa network submission
(December).

Andy: Still going ahead. Working on adding writeback.

[A] for Suzi: Decide if it be Ian or Suzi as PI. Can issue reciprocal
letters of collab.

[A] for Steve: Combine das and das2 lists. Can they be merged.
Check into best way to do this: bounce with message to repost, or
automatically forward anything sent to das2 to the das list
(better). Also: make steve admin on das list, add members from das2 to
das1

Gregg: Important to recover the early discussions

Lincoln (not on this call) is on paternity leave (10/11 girl)

Ann: Ad hoc meetings or regular?
Consensus: regular

Suzi: q for sanger/EBI - how many people would care about das spec?
Doesn't sound like all stakeholders are on the line.

Andy: Quite a few do, but not all can find time to participate. quite
busy. I will serve as their representative for these calls.

Topic: Authentication
===========================

David Nix: Security and auth. What's going on with that?
Summary: I work in core facility, get requests to process data,
private, to be hosted on das server, return to PIs, log into das
server and retrieve data. I hacked into genoviz das2 server a way to
do it, not built into spec, but is really needed. Want to compare
private tracks to public.

We have many diff groups with diff folders, each needs diff permission
settings (lab only, lab + collabs, organization only). Came up with a
custom solution on the das2 servlet rather than a standard http-based
authentication route.

One possible approach: Issuing a special types request suited for that
person. 

GH (Gregg): We only used http auth, worked for us, but is all or none access
to a das source. differentiating based on types w/in an

Steven (UNC): Looking into http authentication. have a test
running. can do arbitrary auth for certain types but not others. Can
force it on a query parameter.

GH: Tomcat realms etc. looking into this.

Steven: Can't to that. Need to create a servelet filter, can send back
a 401 on any server you want auth on.

Nix: Concern: for some labs, they want to keep the genome they're
working on to be private. Do you have to make a request for the track
before you're allowed to see it (e.g., dnase footprinting track)?

steven: challenge response, so server would leak track names. But you
can hide tracks from users if they're not authenticated. Comes down to
the implementation side, not the spec.

GH: running multiple servlets problems could be because of gregg's
implementation. Should be no problem for diff servlets running in same
tomcat. Genometry server was impl under assumption that it's data
model might be shared between diff servlets. Might need to be fixed.

Nix: I have >30 folders. Running so many diff servlet instances would
be insanity.

Concerned about management of permission files. Want someone to
administer via webpage, not a sysadmin. Want to enable lab managers to
add users, change permissions w/o having to send requests to
core lab developers/sysadmins.

Steven: Policy file is java policy file (Using jazz for security
framework). Have flexibility of where policy info is stored. Could be
managed via database.

UK folks security needs?
Intend to use openId system to do authentication. Permissions would be
downstream from authentication. Permissions attributed to different
users haven't been addressed yet. Two separate issues.

UK: Auth is performed by delegate servers.
works across the whole system, rather than having server-specific

Das registry uses it now.

GH: Security/auth is orthogonal to the spec. should be kept separate.

UK: Expectations should be indicated.

Steven: Spec should say that it supports protocol somehow, but not go
into implementation-specific things.
E.g., Do you need to authentical before you can see anything

UK: Good thing about OpenID

Steven: Worry: most client libraries and langs do not support it, whereas
http
auth is more widely supported.

Suzi: There won't be lots of people writing clients, just lots of users.

GH: Concern about putting anything about seecurity and auth into the
spec, adds more to debate about. We've got 3-4 different options
already. Would like to keep it out of the spec.

Suzi: The need is there given interest addressed here. We should say
something about it in the spec. Need to pick one.

UK: Anyone reviewing this proposal will ask about it.

[A] for someone: Need a summation of the pros and cons, bite the bullet and
choose
a path. Need a person to review descriptions and make a decision.

Ann: Would be good to have a statement of pros and cons of different
positions. But yes, a final decision should be there.

Suzi: Someone else could review/summarize a different person's
suggestion.

UK: Agree.

Suzi: I will be reviewer.

[A] Gregg will forward our off-list discussions to the list to get input
from others.

Nix: Don't care so much about impl. Really need a way to formulate a
custom response to an individual. Would be great solve via best
practices. 

SC: Security/auth will be very important with the growing interest in
personalized medicine. Great to get this nailed in the spec.


Topic: Das1-2 spec merging
===========================

GH: Has everyone had a chance to review Andy's writeup?

Suzi: Anyone gone through point by point to see where diffs lie?
GH: Yes. While at Sanger. Meeting about making changes to das 1.5
spec. Talked about hybridizing them. Have side-by-side UML models.

[A] Gregg will send out side-by-side UML models (pictures and/or model
files).

GH: Re integration: Andy said biggest issue for sanger/ebi/biosapiens
is backward compatibility (lack thereof) for das2

Suzi: what pieces in das2 spec are not backwards compatibile? Which
features that are fundamentally different?

GH: working on making das1-> das2 proxy. Very aware of the diffs:
Summary: (see das plan from Jonathan and Andy for change needed to
das1.5 spec)
1) the notion that everything has unique URI in das2  (das1 things
   have
2) hierarchical features
3) Location spec of features (0,1, many) covers gene das and das1
   alignments. We condensed down the alignments into annotations that
   have potentially multiple locations, Bridging these can be
   challenging.
4) Alternative content types. Negotiated between client-server. Enable
   returning back much more efficient format than xml.

Suzi: could that sit on top of something than can/can't negotiate?
GH: Maybe. But gets to backward compatibility. Changing optional <->
required breaks compatibility.  E.g., saying you can ignore anything
you don't understand.

Jonathan: Non lossy conversion? Important for getting people on
board if it is lossy.

GH: Forward from das1->das2 is possible. Das2 allows injection of
arbitrary xml (which can be das1 xml). Not possible in reverse
direction. Looking into proper translation into das2 elements and also
preserve das1 xml.

Suzi: Motivations are still the same. Revisiting the specification, we
all have same issues. Ability to deal with hierarchical data. Seems
very important. Should be translatable non-lossy.

GH: Not translatable in a std fashion. It's a standard you'll have to
force on top of das1 spec to achieve this.

Suzi: Motivations for changing where we are, are the problems we're
trying to solve the same (for 1.5 or 2)?

GH: Main dichotomy is mainly proteins vs genomes vs genes. Stuff built
in das2 may not be appropriate for proteins (slices of annotations on
a range -- you want all of them). Similarly regarding types, might want a
better
breakdown of things without sending all proteins.

Andy: Not many diffs in what we're trying to achieve. Need to
determine whether we want to change a server to support a
protocol. Much more difficult. Once we solve the gaps in das1. Need a
way upgrade without a complex process, w/o using das1 proxy.

Suzi: not a viable long-term solution.

GH: Hard to make tweaks to a spec that uses XML the way that Das1
uses it w/o breaking ba
gene das says you don't need start/stop. Takes two required args and
makes them optional. E.g., my client assumes there's a start and stop
so will break.

Andy: Will still process the request...

GH: Disagree for gene das. Send a query asking for all feats, and you
get something back w/o start-stop.

Andy: Far fewer clients than you have servers. Changing servers is
harder than clients.  Different degrees of "breaking".

Suzi: you mean implementations, right? Might be more instances of
clients running, but more different types of servers?

Andy: Fewer client installations than there are servers, since most
clients are web based.
Suzi: I was counting all web based ones as well.
UK: Using Java web start, clients can be updated automatically.

Suzi: How move forwared.

GH: Implementing das1 proxy, to help people (and self) be aware of
the differences. Posted code to Google code proj. Project=Genomancer
(necromancer for genes!)

[A] gregg - write proposed changes to sources document more formally.
Sanger/EBI are working on 1.6 which includes sources. Rev das2 to have
more updated source command as well.

Jonathan, Andy: [Lots of chop on the phone line] Validation for
registry using XSD. Also ddding requested features to the das
spec. Need to see where it's being used.

Suzi: We want to have one single spec.

UK: Right.

GH: RelaxNG for the sources command?

UK: Just started. haven't used it before.

Someone: Why using XSD?

Andy: Need better validation. Newer commands using XSD, since no one
is using DTDs.

Suzi: Why not consider RelaxNG. I used to be a XSD person, but have
become a fan of RNG.

UK: We can look at it.

GH: Andrew (Dalke) convinced me to use RNG and I've been pleased. XSD
is difficult to read/work with.

UK: It's not too late to change it.

Suzi: We want one spec. Treat it like a football. One person holds it
at a time. pass it back and forth. Multiple editors can be a
problem. Need to be sympathetic with people who come in with
requirements.

GH: For das2 grant, I appointed Andrew as spec czar. Only he could
make changes to the formal schema, other can change HTML docs. Avoided
conflicts in the schema.

UK: [lots of chop on line]. Doing a small remediation to the 1.5 spec,
then we'll have a spec that can incorporate more of the das2
requirements.

[A] UK folks: Continued Das integration work.

Suzi: One spec czar + multiple html editors.
GH: I gave Andrew veto power, but if he abuses it, we'd depose him!
GH: Needs to be called something different. Das3?
Suzi: no! 
UK: Just DAS?
Suzi: Yes, "Das", with releases.

[A] Anyone interested in contributing: look at links from Andy/Jonathan on
how das1 is changing.

Ann: Das2 spec for making changes to genometry server. How to edit
this doc so changes can be rolled back in?  HTML.

GH: Steve?

SC: Yes, I can work on wikifying the existing DAS HTML spec on the
biodas.org wiki.

GH: Like the idea of wikifying them. Next week?

Ann: Stable HTML version + separate live document

[A] Steve wikify the HTML docs.

John (UNCC): Genomancer code is up to date?

GH: Yes, but not usable yet. Das2 -> das2 proxy ok, but needs
docs. But das1-> das2 is not functional yet.

SC: What's purpose of das2 to das2?

GH: das2->das2: can do lots of interesting things: Inject alt content
format. Serve json from a single das2 point. Lots of stuff...

[A] All: Teleconf in two weeks, same time, but need better phone line!



------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.


From aloraine at gmail.com  Thu Oct 30 04:07:04 2008
From: aloraine at gmail.com (Ann Loraine)
Date: Thu, 30 Oct 2008 00:07:04 -0400
Subject: [DAS2] using ProServer as a DAS source for IGB
In-Reply-To: <50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>
References: <C5226153.6B9%hans-rudolf.hotz@fmi.ch>
	<50158cb00810291933m25631c07jaab92cebcc741efc@mail.gmail.com>
Message-ID: <83722dde0810292107y41bdd9c8s4893d44fa7df62fe@mail.gmail.com>

I think Dr. Hotz is describing a difficulty many people have
experienced when working with IGB -- the various methods for loading
data into the browser are very confusing.

Here at Charlotte we're working on a new interface that aims to solve
this problem and make IGB much easier to operate.

One goal for the new data-loading interface is to let the user perform
essentially the same operations for loading data regardless of whether
the data are flowing from a DAS1 site, a DAS2 site, or from files on
the user's file system. (In the latter case, the user might need to
provide a simple file describing how the genome is put together, e.g.,
like the mod_chromInfo.txt from the old QuickLoad scheme.)

I'm working on a design document and will circulate it to anyone who
is interested in commenting or offering suggestions. Dr. Holtz please
let me know if this something you might like to do!

Sincerely,

Ann Loraine


On Wed, Oct 29, 2008 at 10:33 PM, Gregg Helt <gregghelt at gmail.com> wrote:
> You're not seeing DAS/2 in IGB because the use of DAS/2 has become an
> integral part of IGB, to the point that it's no longer advertised as such.
> This was partly motivated by feedback at Affymetrix (internally and from
> customers) that DAS1, DAS/2, any mention of these things in IGB was just
> confusing to users who didn't know what those were and didnt' really care
> what protocol was being used, they just wanted to see the data.
>
> So (unless you've tweaked some advanced prefs) when IGB first launches, goes
> to a particular genome assembly, a particular chromosome, and pulls up the
> chromosomal banding pattern and RefSeq annotations for that chromosome, all
> that is happening via DAS/2.  The "Pick Genome" button that's used to switch
> to a different genome assembly uses DAS/2.  The data access panel at the
> bottom of IGB that allows you to select other annotation types to load is
> using DAS/2.  The tricky bits of ID-to-genome-coordinate resolution that
> happen behind the scenes if you load an Affymetrix gene or exon chp file
> uses DAS/2.
>
> Now there's a whole separate chunk of code in IGB that enables getting
> annotations from DAS1 servers, which is accessed via the File-->"Access
> DAS/1 Servers" menu item that you mention.  This is a much older code base,
> and for some DAS1 servers it works, but for many others it doesn't.  For
> your particular case I'm guessing that the IGB code is ignoring the
> X-Das-Capabilities header and assuming that your server supports "types",
> "features", and "entry_points" queries (or points to a MapMaster that
> supports "entry_points" queries), and it's choking when it turns out the
> server doesn't support either "types" or "entry_points".  This is definitely
> a bug in IGB, and it didn't get fixed back when the IGB DAS1 client was
> being developed because the DAS1 servers that most IGB users were accessing
> at the time didn't trigger this bug.
>
> Assuming the problem is with IGB's handling of DAS1 servers, there's several
> possible solutions.
>
> 1) Configure your DAS server to support all three of the queries the IGB
> DAS1 client needs: "types", "features", "entry_points".
>
> 2) Trellis/Ivy, the DAS1-->DAS2 proxy I've been developing, might work for
> this situation.  Currently it probably won't, as the IGB DAS/2 client also
> requires that the DAS/2 data sources support the DAS/2 "types" query.  But
> this code base is evolving rapidly, and soon the proxy may be able to inject
> type support for DAS1 servers that don't support "types" queries.  It
> already does this kind of injection of the DAS/2 "segments" query for many
> DAS1 sources in the Sanger DAS1 registry that don't list a
> "das1:entry_points" capability.  One caveat to this approach is that
> Trellis/Ivy supports the "sources" query but not the "dsn" query, and may
> not ever since it looks like "dsn" may soon be deprecated.  Does ProServer
> support the 1.53E "sources" query as an alternative to "dsn"?
>
> 3) Modify IGB so it can deal with DAS1 servers that don't support "types"
> and "entry_points" queries.  But I'm reluctant to dive back into the old IGB
> DAS1 code, and I doubt if anyone else wants to either.
>
> 4) Modify IGB so it can deal with DAS/2 servers that don't support "types"
> and "segments" queries.  This is going to happen eventually, it's just a
> question of timing.  Then Trellis/Ivy could be used as-is to proxy for the
> DAS1 server and respons to IGB DAS/2 queries.
>
> If it's straightforward to configure the DAS1 server to support "types" and
> "entry_points" queries, then that's probably the quickest route.
>
> One other caveat -- in order for IGB to overlay annotations from multiple
> data sources, it needs to realize that they're using the same coordinate
> system.  If coordinate system IDs don't match exactly, IGB uses a synonym
> resolution strategy which usually relies on the synonyms doc at
> http://netaffxdas.affymetrix.com/quickload_data/synonyms.txt .  If you can't
> overlay annotations from multiple servers it's probably because their
> coordinate IDs aren't listed as synonyms.  Let me and/or Steve Trutane know
> (steve_chervitz at affymetrix.com) and he can add them in.  Hopefully increased
> use of the DAS1 and DAS2 registries will lessen IGB's dependence on synonym
> resolution.
>
>      hope that helps,
>      Gregg
>
> On Mon, Oct 20, 2008 at 7:24 AM, Hotz, Hans-Rudolf
> <hans-rudolf.hotz at fmi.ch>wrote:
>
>> Hi
>>
>> Your e-mail was given to my by Andy Jenkinson one of the ProServer
>> (http://www.sanger.ac.uk/Software/analysis/proserver/) developers at the
>> EBI
>> in Hinxton, UK).
>>
>> I am struggling to understand which DAS protocol is used in IGB. All the
>> menu tabs are suggesting it is DAS/1 (eg File-> "Access DAS/1 Servers").
>> But
>> the release notes suggest is DAS/2. And if I try to load data from my
>> ProServer I get:
>>
>>   Error parsing DAS Source
>>   org.xml.sax.SAXParseException: Content is not allowed in prolog.
>>
>>
>> Is there a way to use ProServer with IGB?
>>
>> Thank you very much for your help
>>
>> Hans
>>
>>
>> Friedrich Miescher Institute
>> for Biomedical Research
>> Maulbeerstrasse 66
>> 4058 Basel/Switzerland
>>
>>
> _______________________________________________
> DAS2 mailing list
> DAS2 at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das2
>


From gregghelt at gmail.com  Thu Oct 30 06:06:01 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 23:06:01 -0700
Subject: [DAS2] DAS Teleconference Thursday October 30th, 9AM PST
Message-ID: <50158cb00810292306i10450b3aq3b60e16122530fdf@mail.gmail.com>

Just a reminder to everyone that there's a DAS teleconference
tomorrow/today, Thursday October 30th, at 9AM PST (4 PM GMT).  In an effort
to confuse people we're trying yet another teleconference number:

US and Canada Dial-in:  1-800-391-1709
International Dial-in:  001-310-539-2229
Conference Bridge#:     747999

Topics:
    Review progress on action items from last week (see Steve's post of
minutes, which lists action items)
    I'd like to give an overview of the Trellis/Ivy DAS1-->DAS2 proxy, and
future plans for it
    ???


Gregg


From gregghelt at gmail.com  Thu Oct 30 06:30:42 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Wed, 29 Oct 2008 23:30:42 -0700
Subject: [DAS2] Fwd: Using HTTP authentication for DAS/2
In-Reply-To: <83722dde0809260602k611fd1a0u8df00b718d819ed4@mail.gmail.com>
References: <457119e10809241559x417e5c1br15193911bcc45ac@mail.gmail.com>
	<916324E1C885C54989449104CB7225B6028EA5EF@EMAIL1.hci.utah.edu>
	<457119e10809250921j18184230g1a0d0e427877d5ef@mail.gmail.com>
	<83722dde0809260601k196062c6pec0ebd69e84728e2@mail.gmail.com>
	<83722dde0809260602k611fd1a0u8df00b718d819ed4@mail.gmail.com>
Message-ID: <50158cb00810292330q727d8699teaa6b3f1ac998c36@mail.gmail.com>

More background on recent discussions regarding DAS security and
authorization.

---------- Forwarded message ----------
From: Ann Loraine <aloraine at gmail.com>
Date: Fri, Sep 26, 2008 at 9:01 AM
Subject: Re: Using HTTP authentication for DAS/2
To: Steven Blanchard <sgblanch at gmail.com>
Cc: Tonya DiSera <tony.disera at hci.utah.edu>, David Nix
<david.nix at hci.utah.edu>, nicol.john at gmail.com, Brett Milash
<brett.milash at hci.utah.edu>, Robb Cundick <robb.cundick at hci.utah.edu>


I'm not sure if I understand the various technical aspects here - my
apologies! I'm also getting up to speed on this particular issue :-)

Do I understand correctly?

If a lab were to set up its own private DAS site to serve unpublished
or preliminary lab data, it sounds as though they could right this
moment use the technique Steven demo'd in his first email. But if they
also wanted to serve free and open data (for example, as a companion
to a published article) then they would need to set up and run an
entirely new instance of the DAS servlet.

One of our big goals in the Loraine group is to deliver a DAS server
to TAIR and possibly iPlant, which would ultimately serve free and
open data. But I would also want for individual labs to be able to set
up their own private resources. In those cases, users would want to
access the public data (e.g., the foundation TAIR8 annotations)  and
view these foundation annotations alongside their unpublished data
sets, e.g, Arabidopsis tiling array data.

TAIR = www.arabidopsis.org

-Ann

On Thu, Sep 25, 2008 at 12:21 PM, Steven Blanchard <sgblanch at gmail.com>
wrote:
> I have not gotten as far as thinking about your second point
> (authorization).  I am still working on just authentication.  My
> official statement is that HTTP authentication will support mixed
> authenticated/unauthenticated access just fine.
>
> That being said, my previous email glossed over the separation of the
> DAS/2 specification and our DAS/2 server implementation.  If we use
> HTTP authentication, we do not have to specify any authorization model
> in the DAS/2 specification.  If we add our own authentication into the
> DAS/2 specification we will also need to add authorization to the
> specification.  I like the ability to leave the authorization details
> to server implementers as one authorization model may not work for
> everyone.  On the client side, as long as a it supports HTTP
> authentication the client will 'do the right thing' when a server
> requires authenticated access.
>
> My other emails cover implementation details related to supporting
> HTTP authentication, so I will not rehash them here.  Now all we need
> to do is decide on whether to add the current
> authentication/authorization model to the specification or to switch
> to HTTP authentication and decide on an implementation strategy.
>
> Thanks,
> ~Steven
>
>
> 2008/9/25 Tonya DiSera <tony.disera at hci.utah.edu>:
>> Hi Team -
>>
>> I'm just getting familiar with this project, so I apologize if I am
>> covering issues already thought through.
>>
>> David, Brett, and I recently devised a security model for our GNomEx
>> application that allows for both public and private access to
>> experimental data. At first glance, DAS would seem to benefit from a
>> similar security model architected at two levels:
>>
>> 1)  A basic access layer, permitting either public access (guest access,
>> no authentication) or private (login) access.  The trick here is that we
>> want the servlet to be accessed both in an authenticated mode and a
>> non-authenticated mode.  I've devised an implementation that relies on a
>> "gate keeper" servlet that I can expand upon if we find this to be an
>> important consideration.  Steve, it sounds like you have a good handle
>> on the HTTP authentication model.  Is there a way we can rely on this
>> standard implementation, permitting both authenticated and
>> non-authenticated access to the servlet?
>>
>> 2)  A data access layer governed by user/group permissions assigned to
>> specific data sources.  This layer would be implemented by servlet
>> application code that would filter data sources based on the user/group
>> permissions assigned to each data source and the scope of visibility set
>> on the data source.  For example, some data sources would be marked as
>> "public" by the submitter and would therefore be visible to all users.
>> Data sources marked as "private" would be visible to only those users
>> belonging to groups permitted to view this data.
>>
>> Thanks,
>>  Tony Di Sera
>>
>> -----Original Message-----
>> From: Steven Blanchard [mailto:sgblanch at gmail.com]
>> Sent: Wednesday, September 24, 2008 5:00 PM
>> To: David Nix
>> Cc: Ann Loraine; nicol.john at gmail.com; Brett Milash; Tonya DiSera; Robb
>> Cundick
>> Subject: Re: Using HTTP authentication for DAS/2
>>
>> When I was testing, I had only password protected one entire genome of
>> the two that were on the server.  Password protecting only particular
>> annotations would be a bit more complex.  Instead of relying on
>> path-based controls, I think that the DAS/2 servlet could generate the
>> 401 Authorization Required internally and force clients to
>> authenticate when necessary.  If the DAS/2 servlet can generate the
>> 401--which I see no technical reason it can not--it would allow a web
>> admin page to modify permissions on the fly instead of having the
>> systems administrator mucking about with the web.xml.  Again, I will
>> need to test to make sure that this is the case before we decide to
>> commit to this path.
>>
>> ~Steven
>>
>> 2008/9/24 David Nix <david.nix at hci.utah.edu>:
>>> Yes, this is slowly coming back my apologies.
>>>
>>> I did look into using the http authentication the problem is the
>>> granularity.  I believe they provide all or nothing access to the
>> servlet.
>>> Thus each lab would have to have their own servlet instance with
>> pointers to
>>> their data. (We've got a growing list of 20 labs with private and
>> public
>>> data.) Most servlet containers explicitly avoid multiple instances and
>> work
>>> with a shared instance.  I looked into running multiple instances and
>> or
>>> multiple tomcat servers and it got rather ugly.
>>>
>>> Is there a way of allowing everyone to access the servlet but passing
>> to it
>>> the credentials from the http authentication?  That would be a good
>>> solution.
>>>
>>> -cheers, D
>>>
>>>
>>> On 9/24/08 2:52 PM, "Steven Blanchard" <sgblanch at gmail.com> wrote:
>>>
>>>> Apologies this rambles a little:  I wanted to get it out while
>>>> everything was still fresh in my mind.
>>>>
>>>> The three types of HTTP authentication I know about are Basic,
>> Digest,
>>>> and Negotiate.  Basic and Digest authentication are the most common.
>>>> Basic authentication sends usernames and passwords across the wire in
>>>> clear text.  Digest authentication uses an MD5 digest of the password
>>>> instead of the actual password itself but can not be used with some
>>>> back-end authentication databases.  Negotiate authentication is
>>>> designed to enable Kerberos and other similar authentication schemes,
>>>> but is not well supported.  The advantage I see to using HTTP
>>>> authentication is that a server administrator can leverage any
>>>> authentication mechanism supported by the servlet server.
>>>>
>>>> As a test, I used basic authentication to  password protect a genome
>>>> on our DAS/2 server.  I chose to use HTTP Basic authentication backed
>>>> by our LDAP directory.  The configuration I created allowed anyone in
>>>> the 'admin' LDAP group to access the password-protected genome.  Note
>>>> that this configuration does transmit passwords in the clear.
>>>>
>>>> When I accessed the protected genome using IGB, it created a login
>> box
>>>> asking for the user to authenticate to the server which worked as
>>>> expected.  The dialog box was created by Java itself: I did not
>> change
>>>> a single line of code in IGB or the DAS/2 servlet.
>>>>
>>>> If we were to adopt HTTP authentication as the offical access control
>>>> method for DAS/2, the following modifications would be required:
>>>>  - Fix the labels on the HTTP authentication dialog box (blank site
>> and realm)
>>>>  - have IGB properly handle 403 Forbidden responses which may be the
>>>> result of failed login attempts (tons of exceptions)
>>>>  - Determine if IGB's browser cache needs fixing (uses cached file if
>>>> it exists and the current authentication attempt failed)
>>>>  - Modify the DAS/2 servlet to manage access control instead of the
>>>> web.xml (Should be possible, but not certain)
>>>>
>>>> The tomcat context.xml (called das2.xml) and web.xml I used are
>>>> attached. A screen capture of the password dialog box presented by
>> IGB
>>>> is also attached.
>>>>
>>>> Please let me know if I need to clarify anything.
>>>>
>>>> Thanks,
>>>> ~Steven
>>>
>>>
>>
>


From gregghelt at gmail.com  Thu Oct 30 08:02:34 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 01:02:34 -0700
Subject: [DAS2] Minutes from 2 October 2008 DAS teleconference
Message-ID: <50158cb00810300102k3248ad29mdd712c827d6026e8@mail.gmail.com>

Better-late-than-never minutes from 2 October 2008 DAS teleconference:

*Roll Call:*
Gregg Helt (unaffiliated: DAS/2, visualization, data modelling)
Suzi Lewis (LBNL: Apollo, etc.)
Ed Lee (LBNL: Apollo, annotation data models)
Ann Loraine (UNC: plant genomics, genomics vizualization)
Jon Nicols (UNC: genomics visualization )
Steven Blanchard (UNC: sys admin, security)
Andy Jenkinson (EBI: coordinator for DAS services at EBI)
Jonathon Warren (Sanger: coordinator for DAS services at Sanger)
Felix Kozinski (Sanger: DAS coordinator for Sanger ENCODE project)

*DAS/2 Status Summary:*
Gregg gave overview, refer to "DAS/2 Grant Final Progress Report" post
(October 2nd, 2008) on DAS/2 mailing list:
http://lists.open-bio.org/pipermail/das2/2008-October/000438.html
Stuff in summary not covered in progress report:
Alan Day is no longer at UCLA, and not working on the biopackages DAS/2
server (chado, BioPerl based DAS/2 server)
Possibility of deploying biopackages DAS/2 server on a MOD chado
installation (BOP? VectorBase?)
Several people at annotation workshop are using Apollo for curation
alongside IGB for viewing dense quantitative data.

*Hinxton DAS1 Summary*
Registry:
    now have DAS1 registry
    was one of the major things missing from DAS1 that motivated DAS2
    most clients use the registry
    about 400 sources in the registry
    implements validation
    uses same sources command as DAS/2
extensions
    alignments
    structures
    interactions
    in general evolving into a much wider system for biodata
core client/server implementations maintained at Sanger and EBI
lots of other implementations using DAS1, so heavy investment in DAS1
writeback
    one preliminary implementattion (partly based on DAS/2 writeback spec),
but nothing solid yet
    grant application being submitted December 8th
        collab between Sanger, EBI, and NBN (South Africa)
        includes writeback component (client and server implementations)
        client will be in DASTY
translation/bridge between protein and genomic space
        another goal of Sanger/EBI/NBN grant in preparation
Revising DAS1 spec (DAS 1.6)
    refer to biodas wiki pages:
        http://www.biodas.org/wiki/Spec_Review
        http://www.biodas.org/wiki/DAS_Plans
    no changes yet to sources, folded in as is from extensions, deprecate
dsn
"DAS is the general weapon of choice for integrating data throughout Sanger,
and largely at EBI as well"


*Other spec revision:*
DAS/2 spec frozen in November 2006, Gregg feels its time for revision
regardless of other integration, should make sure sources spec evolves in
sync between DAS1/2
Gregg's revisions: Two Plans
    #1.  DAS 2.1 --> relatively minor revisions to spec
    #2   no name yet --> much larger change
            possibly integrating DAS1 and DAS2
            move on top of Atom/AtomPub/GoogleData stack

*Andy -- DAS1 and DAS2*
    #2 above seems to be a good direction to go in from a technical
standpoint
    but, DAS/2 as it stands also seems to be good from a technical
standpoint
    major sticking point is backward compatibility with DAS1
    doesn't see how can convince powers that be to commit to DAS/2 without
backward compat
    other alternative is if there's a proxy that is very successful at DAS1
--> DAS/2 conversion
    Gregg -- still working on proxy, has expanded scope
            about a week away from usable
            proxy: DAS1.53 - dsn + sources
            source code going up on google code project hosting

*DAS2 Funding*
    Ann: recently awarded grant includes funding for DAS/2 arabidopsis
server
            wants to expand to cover many plants
            hopefully deployed at TAIR
            Suzi -- TAIR is using Apollo
            visualization
            UI improvements to IGB
            surveying different genomics visualization tools
            want to have easy way for small data providers to host data
            support/development of GenoViz toolkit
    Gregg:
           Lincoln committed to putting someone on DAS/2 client/server
support for GBrowse
           Gregg, Suzi, Ian Holmes discussing putting in distributed
annotation grant
                submit to NIH Feb 2009
                combine ideas and code from Apollo, JBrowse, IGB, DAS/2
                GMOD help desk now at UNC -- may be interested in joining in

    Andy -- prospects for grant focused on DAS itself as opposed to DAS
within other projects?
    Gregg -- problematic.  already had DAS/2 grant from NIH
    Suzi -- NIH now wants biology driving projects -- plain infrastructure
things don't tend to fly
    Gregg -- maybe could get funding again, but first need more results from
initial DAS/2 grant
                tried big reup three years ago, didn't fly
                need to get a paper out, more sites using
    Andy -- what would help is involvement of major institution
    Gregg -- but we tried with UCSC and PDB in reup, may have helped but
still didn't get funding
                involvement of major data repository necessary but not
sufficient for funding
    Andy -- in Europe industry partnership very important when asking for
funding now
            possibility of funding to build network of integrated EBI
resources based on DAS,
            that industry could use,
            possibility of money from UK/Europe, but probably need to use
what funding already have
    Ann -- what about developing a web services RCN (Research Coordination
Network) via NSF
            example: Microarray Coordination Network
            includes outreach
            in plant community people are using BioMoby a lot, but it's
complicated to use?
            Ann will look into NSF RCN funding possiblities
            iPlant (NSF)
    Sanger and EBI funding for DAS comes mostly from core informatics funds
    Andy -- discuss joining DAS1 and DAS2 in NSF proposal?
               would want institutes on both sides of the pond
    Suzi -- UCSC over here?
    Gregg -- I think they'd be amenable


*Action Items:
*schedule for DAS/2 teleconferences: every other Thursday @ 9AM PST
what are we talking about at the next one?
        get specific about specification changes
        start listing specific aims for grant proposals


From gregghelt at gmail.com  Thu Oct 30 10:31:42 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 03:31:42 -0700
Subject: [DAS2] authentication: don't bake anything into the spec
Message-ID: <50158cb00810300331w2ea4c9d7lf5ebbab25d79395b@mail.gmail.com>

As part of our review of different authentication mechanisms to integrate
into the DAS specification(s), I volunteered to summarize the pros and cons
of the null hypothesis.  That is, not "blessing" any particular
authentication strategy in the DAS protocol itself, but rather leaving
authentication to be determined by the server and client implementations
that need it.

To avoid too many double negatives, I'll flip that around and discuss pros
and cons of having any authentication embedded in the spec.

Cons of having authentication strategy embedded in the DAS protocol:

1) Increases spec complexity.

2) If it's required, then increases development overhead for client and
server implementations that don't need it or need to use an alternative
strategy.

3) May negatively impact adoption by some organizations.  Blessing a
particular authentication strategy, even if alternatives are allowed, can
have a dampening effect on adoption by organizations that need to use an
alternative strategy.  In other words, the protocol may be viewed as being
optimized for the blessed strategy at the expense of others, increasing the
chances of a more agnostic alternative being adopted instead.  Even if the
bioinformatics folks at an organization want to use DAS, in many
organizations (at least the corporate ones) they have little influence on
security-related technology decisions.

Pros of having authentication embedded in the DAS protocol:

1) More likely that client and server implementations can be used "off the
shelf" as long as the authentication needed is met by the blessed strategy

2) By virtue of (1), may positively impact adoption by some organizations

3) Promotes uniformity across various implementations


From gregghelt at gmail.com  Thu Oct 30 12:17:15 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 05:17:15 -0700
Subject: [DAS2] DAS URI resolvability
Message-ID: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>

Sorry, I think I confused the issue again -- I seem to be on a terminology
abuse binge.  I used "addressable" and "addressability" in referring to URIs
when I should have used "identifiable" and "identifiability".  Please
mentally do s/addressable/identifiable/g and
s/addressability/identifiability/g on everything I've written in the past
week...

I think you and I are in agreement as far as whether DAS URIs should be
resolvable.  Quoting myself from a previous thread I forwarded to the list
last night (with terminology corrections applied):

In general as part of a spec revision (DAS 2.1?) I'd like to eliminate more
of the resolvability requirements in the specification, and specify that
most URIs be used as identifiers with _optional_ resolvability.  After two
years of working with the current spec I've come to believe that for most
cases requiring resolvable URIs is not necessary, places added burden on
server implementations, and limits the ability to do non-authoritative
decentralized annotation.

The spec can be stripped down so that the only URI references required to be
resolvable are those specified by the "query_uri" attribute of the
CAPABILITIES element.

The only problematic part in the DAS/2 annotation retrieval spec would be
the segment URIs.  The current spec needs these to be resolvable as that's
the mechanism used to retrieve residues for a particular segment/sequence.
But I think this could be revised without too much implementation overhead
to merge residues retrieval and the segments query to make something more
like a hybrid of the DAS2.0 segments and DAS1.53 sequence queries.

       Gregg

On Wed, Oct 29, 2008 at 12:04 PM, Andy Jenkinson
<andy.jenkinson at ebi.ac.uk>wrote:

> The difference between an ID and a URI is not so great, any ID can be a URI
> if we refer to the URN definition. But whether this URI should be resolvable
> (that is, a URL) is a big question. Whilst it is certainly a nice thing to
> be able to do, I'm not convinced of the practicality given the relationship
> between simplicity and adoption of technologies like DAS.
>
> Ignoring the difficulty in making something actually resolvable (which can
> potentially be accomplished for features by just having "
> http://server/das/source/features?feature_id=foo") there is more pressure
> than ever on keeping verbosity low, and I'm not sure if this can be
> accomplished as things are right now when you have different URI prefixes in
> the same document. Gregg, perhaps you can elaborate?
>
> I know you also advocate alternative content negotiation to solve this
> issue - do your alternative formats contain these URIs or do they strip
> them?
>
> Gregg Helt wrote:
>
>> Using the DAS/2.0 specification, this idea of "annotations of annotations"
>> is easy to do.  That's because every feature in DAS/2.0 has a unique URI and
>> is therefore addressable by _any_ other system that uses URIs -- including
>> another DAS/2.0 server:
>>
>> <FEATURE uri="http://somewhere.else/feat123" ... >
>>     <PROP key="my_thoughts_on_feat123" value="overexpressed in tissue XYZ"
>> />
>> </FEATURE>
>>
>> Or if you prefer allowing your meta-annotation to have it's own URI:
>>
>> <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>
>>
>> Used in this way DAS/2.0 becomes very RDF-like..
>>
>> This is not just a happy accident but the result of a central tenet of
>> DAS/2 -- addressability of all important DAS/2 entities outside the local
>> system via URIs.  The DAS/2 writeback spec is built on top of the DAS/2
>> retrieval spec, so if you're fully implementing the writeback spec you
>> should be able to use this ability to do meta-annotations.
>>
>>      Gregg
>>
>

On Wed, Oct 29, 2008 at 3:15 PM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Gregg Helt wrote:
>
>>
>> Sorry for being imprecise about URIs, what I meant to say was that every
>> feature in DAS/2.0 has a unique _absolute_ URI.  Most IDs can be treated as
>> relative URIs but not absolute URIs, and referring to relative URIs is not
>> particularly useful outside their context.
>>
>
> By relative URI do you mean URN (e.g. SO:12345)? As opposed to the HTML
> definition (e.g. index.html). URNs are still useful since they allow us to
> solve this issue of identifying things that are the same. A resolvable URI
> (i.e. a URL) is undoubtedly "better", but this is semantic web territory and
> I'm not convinced it is necessary for DAS. Certainly I think it would be too
> much a constraint to layer onto the existing spec in one increment. In fact
> even using URNs is not easy for everything - segment IDs cannot have colons.
>
>


From andy.jenkinson at ebi.ac.uk  Thu Oct 30 14:09:46 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:09:46 +0000
Subject: [DAS2] DAS URI resolvability
In-Reply-To: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>
References: <50158cb00810300517g51adcf26yb1d657fe0c4c1fca@mail.gmail.com>
Message-ID: <4909C02A.30501@ebi.ac.uk>

Gregg Helt wrote:
> Sorry, I think I confused the issue again -- I seem to be on a 
> terminology abuse binge.  I used "addressable" and "addressability" in 
> referring to URIs when I should have used "identifiable" and 
> "identifiability".  Please mentally do s/addressable/identifiable/g and 
> s/addressability/identifiability/g on everything I've written in the 
> past week...
> 
> I think you and I are in agreement as far as whether DAS URIs should be 
> resolvable.  Quoting myself from a previous thread I forwarded to the 
> list last night (with terminology corrections applied):
> 
> In general as part of a spec revision (DAS 2.1?) I'd like to eliminate 
> more of the resolvability requirements in the specification, and specify 
> that most URIs be used as identifiers with _optional_ resolvability.  
> After two years of working with the current spec I've come to believe 
> that for most cases requiring resolvable URIs is not necessary, places 
> added burden on server implementations, and limits the ability to do 
> non-authoritative decentralized annotation.
> 
> The spec can be stripped down so that the only URI references required 
> to be resolvable are those specified by the "query_uri" attribute of the 
> CAPABILITIES element. 

Great, I think we're on the same page.

> The only problematic part in the DAS/2 annotation retrieval spec would 
> be the segment URIs.  The current spec needs these to be resolvable as 
> that's the mechanism used to retrieve residues for a particular 
> segment/sequence.  But I think this could be revised without too much 
> implementation overhead to merge residues retrieval and the segments 
> query to make something more like a hybrid of the DAS2.0 segments and 
> DAS1.53 sequence queries.

Keeping one eye on our plans for the future, I think it's worth bearing 
in mind that DAS has many more "coordinate systems" than genome 
assemblies, and only some of these are sequence.

DAS clients need to be able to get:
1. a list of reference entities
2. reference data (sequence, structure) for a single entity
3. annotation data (features, interactions) for a single entity

We could combine 1 and 2 as you suggest, but the size of the data would 
mean it would have to emulate separate command (i.e. get me a list of 
sequences, but don't give me the sequence) so we might as well keep them 
separate (e.g. entry_points + sequence; entry_points + structure).

Incidentally, the concept of a segment is far less important in DAS now 
so it's probably too specific as a command name (shout if that needs 
explanation...).


From andy.jenkinson at ebi.ac.uk  Thu Oct 30 14:24:54 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:24:54 +0000
Subject: [DAS2] [DAS] [Fwd: Re:  Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk>
	<4908837C.1000902@nbn.ac.za>	<490891A4.8050908@ebi.ac.uk>
	<4909821B.6050300@nbn.ac.za>
Message-ID: <4909C3B6.4060104@ebi.ac.uk>

Gustavo Salazar wrote:
> Now that all of you points about the URI field, i have notice that in 
> the Asia's implementation the attributes of the FEATURE tag have changed 
> in relation of the examples in the published protocol( 
> http://biodas.org/documents/das2/das2_writeback.html), and for example 
> there is not a uri attribute and is replaced by featureid, the example 
> for the tag FEATURE in her document is:
> 
> <FEATURE featureid="ADCK2" featuretype="exon" method="experiment">

I would have expected the <FEATURE> structure to be the same as the 
features command, could a DAS/2 person comment on the difference?

So long as the data relationships are the same I guess it doesn't matter 
(i.e. one type, which has an ID, a category and label; one method...). 
But does it?

One difference I have noticed between DAS and DAS/2 is that in the 
latter a method is an attribute of a type rather than a feature - this 
means you can't have two features, both of type SNP, identified by 
different methods... I believe it's implemented this way in the DAS 
types command too, and I'm planning to remove it from the spec.

> I have also notice that for properties in that implementation is used a 
> tag <PROPERTY> but Gregg used <PROP> in his example

This changed at some point - I believe PROP is correct.


From andy.jenkinson at ebi.ac.uk  Thu Oct 30 14:28:14 2008
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 30 Oct 2008 14:28:14 +0000
Subject: [DAS2] [DAS] [Fwd: Re:  Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk>
	<4908837C.1000902@nbn.ac.za>	<490891A4.8050908@ebi.ac.uk>
	<4909821B.6050300@nbn.ac.za>
Message-ID: <4909C47E.4070302@ebi.ac.uk>

Gustavo Salazar wrote:
> Hello,
> 
> Thanks for your comments.
> 
> In the Asia's implementation the ADD command is implemented by default 
> i.e. that if the UPDATES or DELETES tags doesn't appears the writeback 
> document is understood as an addition. I am implementing this in the 
> same way.

This seems fair.

> About the use of UPDATE instead of setCurrent is a good idea easier to 
> implement in client and server, however the getHistorical command still 
> looking to me as necessary.

Provenance is an important thing so functionality of this nature is 
something I would like to see. I expect this is something that anyone 
looking to use writeback in a genome annotation context would want too, 
perhaps Suzi could comment?


From gregghelt at gmail.com  Thu Oct 30 15:20:09 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:20:09 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4909C3B6.4060104@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
	<4909C3B6.4060104@ebi.ac.uk>
Message-ID: <50158cb00810300820r4a0c528brb7bdea6331224eca@mail.gmail.com>

In the DAS/2 writeback spec (
http://biodas.org/documents/das2/das2_writeback.html), the <FEATURE>
structure is the same as that returned in the DAS/2 features query, with the
single addition of an "old_uri" attribute in the writeback response.

Asia implemented things differently, and the result partly follows the DAS/2
writeback spec, but with bits of DAS1 and other things mixed in.  There's a
discussion of these changes in her master's thesis on the writeback
implementation (
http://daswriteback.googlecode.com/files/Thesis_corrected.pdf ).

On Thu, Oct 30, 2008 at 7:24 AM, Andy Jenkinson <andy.jenkinson at ebi.ac.uk>wrote:

> Gustavo Salazar wrote:
>
>> Now that all of you points about the URI field, i have notice that in the
>> Asia's implementation the attributes of the FEATURE tag have changed in
>> relation of the examples in the published protocol(
>> http://biodas.org/documents/das2/das2_writeback.html), and for example
>> there is not a uri attribute and is replaced by featureid, the example for
>> the tag FEATURE in her document is:
>>
>> <FEATURE featureid="ADCK2" featuretype="exon" method="experiment">
>>
>
> I would have expected the <FEATURE> structure to be the same as the
> features command, could a DAS/2 person comment on the difference?
>
>
>


From gregghelt at gmail.com  Thu Oct 30 15:27:00 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:27:00 -0700
Subject: [DAS2] Fwd: A case for why we need authentication/ login
	functionality in the DAS specifications
In-Reply-To: <C51E28AA.5F8F%david.nix@hci.utah.edu>
References: <C51E28AA.5F8F%david.nix@hci.utah.edu>
Message-ID: <50158cb00810300827o56738242t8f86363d87559807@mail.gmail.com>

On Thu, Oct 30, 2008 at 7:47 AM, David Nix <david.nix at hci.utah.edu> wrote:
Hey Gregg, I don't think my summary went out to the das mailing lists.  It
came back last week rejected for lack of permission to post.  Could you
forward it?  -cheers, D


---------- Forwarded message ----------
From: David Nix <david.nix at hci.utah.edu>
Date: Fri, Oct 17, 2008 at 10:34 AM
Subject: A case for why we need authentication/ login functionality in the
DAS specifications
To: das2 at lists.open-bio.org, Gregg Helt <gregghelt at gmail.com>, Tonya DiSera
<tony.disera at hci.utah.edu>, Brett Milash <brett.milash at hci.utah.edu>, Robb
Cundick <robb.cundick at hci.utah.edu>, Ann Loraine <aloraine at gmail.com>,
Steven Blanchard <sgblanch at gmail.com>, Suzanna Lewis <suzi at berkeleybop.org>,
Andy Jenkinson <andy.jenkinson at ebi.ac.uk>


Hello Folks,

Here is a case for why we need authentication/ login functionality in DAS.

Key Functionality: Need a mechanism to tell a DAS server who is making a
particular request.

This will enable tailor-made responses such as:

1) Access to private data (sources, segments, types, etc.)
2) Custom views of the data (investigator view vs clinic view of same data)
3) Restricted write back
4) Support future as of yet undefined personalized responses

How this is implemented is of little concern to me so long as the key
functionality is met.

That said, a couple of considerations for any DAS Server implementation:

1) Web forms/ GUIs should be capable of modifying the users, user
permissions, data views and uploading of new data. Privileged users with no
command line skills (ie biologists/ lab managers) need to be able to
customize their data and who can see it. They shouldn't have to make a
request to a system administrator.

2) The mechanism of passing the user credentials to the servlet should be
platform independent. The fewer barriers to installing a DAS server the
better. A good DAS server should support authentication on WebSphere,
Tomcat, Orion, etc. with little to no modification.

A first stab:

I've build into the current GenometryDas2Servlet a mechanism for
authenticating a client. I tried to follow existing DAS/2 query/ response
styles.

In brief, I created a new DAS command called 'login' that prompts the
servlet to check to see if this server instance is authorizing. If it is not
authorizing (ie contains no restricted sources/segments/types) then an xml
doc is returned with an AUTHORIZED tag set to true. If it is authorizing and
no login parameters are provided with the request then the AUTHORIZED tag is
set to false. If the server doesn't recognize the login request then it's
HTTP ERROR: 400 response also says it isn't accepting authorization.

Thus a login request without parameters basically is asking to see if
authentication is recognized and, if so, enabled.

If 'user' and 'password' parameters are supplied with the 'login' request,
the servlet attempts to authenticate the user, if OK an HTTPSession object
is created for the user, a JSESSIONID is attached to the xml response as a
cookie and the AUTHORIZED tag set to true.

I modified IGB to make a 'login' request to each DAS/2 server listed in it's
igb_pref.xml file upon start up. If the DAS/2 server responds appropriately,
IGB asks the user to enter a login and password.  These are then sent as
plain text parameters (bad, need a better mechanism, https?) with a second
login request. Authentication then proceeds.  If the server doesn't
recognize the login request (throws an HTTP ERROR: 400) or it isn't enabled,
the user isn't prompted and no login information is sent. See the attached
file for some examples of the exchange.


-cheers, David


--
David Austin Nix, PhD | HCI Bioinformatics | Huntsman Cancer Institute |
2000 Circle of Hope | SLC, UT 84112 | Rm: 3344 | Vc: 801.587.4611 | Fx:
801.585.6458 | david.nix at hci.utah.edu |
http://bioserver.hci.utah.edu/BioInfo/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loginResponses.xml
Type: text/xml
Size: 1349 bytes
Desc: not available
URL: <http://lists.open-bio.org/pipermail/das2/attachments/20081030/1729334b/attachment-0002.xml>

From gregghelt at gmail.com  Thu Oct 30 15:36:17 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Thu, 30 Oct 2008 08:36:17 -0700
Subject: [DAS2] A case for why we need authentication and login
	functionality in the DAS specifications
Message-ID: <50158cb00810300836j75f4289fya593fc7fb74ec59@mail.gmail.com>

On Thu, Oct 30, 2008 at 7:47 AM, David Nix <david.nix at hci.utah.edu> wrote:
Hey Gregg, I don't think my summary went out to the das mailing lists.  It
came back last week rejected for lack of permission to post.  Could you
forward it?  -cheers, D

---------- Forwarded message ----------
From: David Nix <david.nix at hci.utah.edu>
Date: Fri, Oct 17, 2008 at 10:34 AM
Subject: A case for why we need authentication/ login functionality in the
DAS specifications
To: das2 at lists.open-bio.org, Gregg Helt <gregghelt at gmail.com>, Tonya DiSera
<tony.disera at hci.utah.edu>, Brett Milash <brett.milash at hci.utah.edu>, Robb
Cundick <robb.cundick at hci.utah.edu>, Ann Loraine <aloraine at gmail.com>,
Steven Blanchard <sgblanch at gmail.com>, Suzanna Lewis <suzi at berkeleybop.org>,
Andy Jenkinson <andy.jenkinson at ebi.ac.uk>

Hello Folks,

Here is a case for why we need authentication/ login functionality in DAS.

Key Functionality: Need a mechanism to tell a DAS server who is making a
particular request.

This will enable tailor-made responses such as:

1) Access to private data (sources, segments, types, etc.)
2) Custom views of the data (investigator view vs clinic view of same data)
3) Restricted write back
4) Support future as of yet undefined personalized responses

How this is implemented is of little concern to me so long as the key
functionality is met.

That said, a couple of considerations for any DAS Server implementation:

1) Web forms/ GUIs should be capable of modifying the users, user
permissions, data views and uploading of new data. Privileged users with no
command line skills (ie biologists/ lab managers) need to be able to
customize their data and who can see it. They shouldn't have to make a
request to a system administrator.

2) The mechanism of passing the user credentials to the servlet should be
platform independent. The fewer barriers to installing a DAS server the
better. A good DAS server should support authentication on WebSphere,
Tomcat, Orion, etc. with little to no modification.

A first stab:

I've build into the current GenometryDas2Servlet a mechanism for
authenticating a client. I tried to follow existing DAS/2 query/ response
styles.

In brief, I created a new DAS command called 'login' that prompts the
servlet to check to see if this server instance is authorizing. If it is not
authorizing (ie contains no restricted sources/segments/types) then an xml
doc is returned with an AUTHORIZED tag set to true. If it is authorizing and
no login parameters are provided with the request then the AUTHORIZED tag is
set to false. If the server doesn't recognize the login request then it's
HTTP ERROR: 400 response also says it isn't accepting authorization.

Thus a login request without parameters basically is asking to see if
authentication is recognized and, if so, enabled.

If 'user' and 'password' parameters are supplied with the 'login' request,
the servlet attempts to authenticate the user, if OK an HTTPSession object
is created for the user, a JSESSIONID is attached to the xml response as a
cookie and the AUTHORIZED tag set to true.

I modified IGB to make a 'login' request to each DAS/2 server listed in it's
igb_pref.xml file upon start up. If the DAS/2 server responds appropriately,
IGB asks the user to enter a login and password.  These are then sent as
plain text parameters (bad, need a better mechanism, https?) with a second
login request. Authentication then proceeds.  If the server doesn't
recognize the login request (throws an HTTP ERROR: 400) or it isn't enabled,
the user isn't prompted and no login information is sent. See the attached
file for some examples of the exchange.


-cheers, David


--
David Austin Nix, PhD | HCI Bioinformatics | Huntsman Cancer Institute |
2000 Circle of Hope | SLC, UT 84112 | Rm: 3344 | Vc: 801.587.4611 | Fx:
801.585.6458 | david.nix at hci.utah.edu |
http://bioserver.hci.utah.edu/BioInfo/


From Steve_Chervitz at affymetrix.com  Thu Oct 30 18:56:43 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 30 Oct 2008 11:56:43 -0700
Subject: [DAS2] Minutes from 30 Oct 2008 DAS teleconference
Message-ID: <C52F517B.33040%Steve_Chervitz@affymetrix.com>

Action items are now summarized at the end of the minutes.

Steve

------------------------------------------------------------------
Minutes from 30 Oct 2008 DAS teleconference

Teleconference Info:
   * Schedule:         Biweekly on Thursday
   * Time of Day:      9:00 AM PDT, 12:00 PM EST, 16:00 GMT
   * Dialin:           See biodas.org community portal page for details

Attendees: 
    Free agent: Gregg Helt
    Affymetrix: Steve Chervitz
    EBI: Andy Jenkinson
    Sanger: Jonathan Warren, Felix Kokocinski
    U North Carolina: Ann Loraine, Steven Blanchard, John Nicol

Note taker: Steve Chervitz

Action items are flagged with '[A]' and are summarized at the bottom of the
minutes.

The teleconference schedule and links to past minutes are
available from the Community Portal section of the biodas.org site:
http://www.biodas.org/wiki/BioDAS:Community_Portal#Teleconference

DISCLAIMER: 
The note taker aims for completeness and accuracy, but these goals are
not always achievable. So don't consider these notes as complete minutes
from the meeting, but rather abbreviated, summarized versions of what
was discussed. There may be errors of commission and omission.
Participants are welcome to post comments and/or corrections to these
as they see fit on the the discussion list.

========================================================

Agenda:
========

* Review progress on action items from last week (based on minutes)
* Gregg give overview of the Trellis/Ivy DAS1-->DAS2 proxy, and future plans


Discussion of action items from 16 oct 2008 teleconf:
=====================================================

Previous action items are underlined, with relevant discussion below.

Suzi: Decide Ian or Suzi is PI on grant. Issue reciprocal letters of collab.
----------------------------------------------------------------------------
--------------

(Pending)  - Suzi is not on this call.

Steve: Combine das and das2 lists. Can they be merged.
--------------------------------------------------------------

SC: Plan is to ultimately have a single das discussion list. Everyone
on das2 list that is not on the das list will be added. Then we can
redirect any posts to the das2 list to go to the das list. Das2 list
will be retained as an archive.

I have been added as an admin on the das list, so now I can work on
migrating users. Also need to update the list description per the new
arrangement.  Haven't had a chance to do this, but will get on it by
mid-next week.

Noticed a fair amount of spam sent to the list that needs
moderation. Original moderators are no longer active.

AJ: We can have the list auto reject messages from non-subscribers.

SC: Good idea. Will reduce moderation burdon.

AJ/JW: Willing to be added as moderators.


Suzi: Summation of authentication pros and cons. Review descriptions, make a
decision.
----------------------------------------------------------------------------
--------------

(Pending)

Gregg will forward our off-list discussions to the list to get input from
others.
----------------------------------------------------------------------------
----

GH: See other's posts to the list. GH's summary.

Gregg will send out side-by-side DAS/1 and DAS/2 UML models (pictures and/or
model files).
------------------------------------------------------------------------

GH: See 29-oct-08 post to the list for these.
JW: Could get technical, esp. for alignments.
GH: Teleconf can be more efficient than email, though face-to-face is best.
AJ: Can put it at the end of the discussion.

Gregg: write proposed changes to sources document more formally.
----------------------------------------------------------------------

(Pending)

UK folks: Continued Das integration work (spec review)
-------------------------------------------------------

JW: No comments posted. Planning to try RNG instead of XSD. Good
suggestion. Working on validation. Will post these next week.

GH: There is a nice RNC mode in emacs, and in-line realtime validator that
will
validate against a document.


Anyone interested in contributing: look at links from Andy/Jonathan on how
das1 is changing.
----------------------------------------------------------------------------
-------------

GH: Regarding DAS changes document, I can start editing with how it
changes for DAS/2. But could get long.
JW: That's fine.

GH: Regarding plans to deprecate the DSN: I like this, but will
require changes to the sources document to fully deprecate
it. Example: Map masters not reflected in the registry.
JW: OK. We're open to any changes.

Steve: wikify the HTML docs.
-------------------------------

SC: Wikified as of last night (10/29). Left-hand nav of biodas.org
link has been updated and DAS/2 page updated to point to wikified spec
at http://www.biodas.org/wiki/DAS/2/Spec

AL: Concerned that it is not noted as "under development". There
should be a fixed version of the spec and a draft version so that
people know what they're using.

SC: Can flag the wikified spec as "evolving" and have pages be
DAS/2.1. The HTML version of the spec can be flagged as "frozen".
Will post a link to the list when ready.


All: Teleconf in two weeks, same time, but need better phone line!
----------------------------------------------------------------------

New number for this meeting is not long-term (GH is paying for).
GH: Can probably use Suzi's long-term. Her laptop is offline
currently, but we should be able to get the info before next meeting.


New Topics
============

JW: DAS workshop at Hinxton on 9-11 March. Tutorial day1, das
project talks das2, hackathon day3, more programming work, das1-2
merging, etc. Not tied to other meeting. Sponsored by BioSapiens.

GH: Love to attend, but need funding. Would like to host a workshop on
West coast at some point. Prob best time 6 mos after UK. Hackathon-style.

SC: Can you post it to biodas.org current events?

AJ/JW: It's not yet been announced. Will do eventually.

AL: Working on changes to das server to support Arabidopsis data and
also some IGB mods. Will test before posting. Hosting of bioviz.org.

Plan to host Java Web start for IGB on bioviz.org, based on SVN
codebase in SF.  

JN: The Affy links to launch IGB on the SF page are broken.

[A] Steve: Fix Affy IGB launching links on SF page.

SC: You will need a code signing certificate because IGB needs to
write to the local disk. Affy's cert is expiring in December, but
don't need to renew if yours will be ready by then. What's
your time frame?

JN: Can look into getting something preliminary posted soon.

GH: Need a release that can support the translational proxy. Will talk
about this with AL offline.


Topic: Gregg's translational proxy
====================================

GH: Has anyone looked at this yet?
AJ: Have looked at code, not XML. Will check it out.

GH: What it is doing: Das ID -> URI conversion. Hit some issues where
some das IDs aren't really URI or URI refs. Using XML base features of
das2, using a shorthand version of the URI (XML base space provides
way to resolve them into full URIs).

Other stuff: tell if a field (e.g., phase or score) is null or not
available, will strip those out to avoid overhead of empty
elements. When there are values which aren't in DAS/2 protocol,
it converts into das/2 properties with "DAS1:" prefix. Seems to work
well. Looked at some examples, none of which had non-nulls, so you
can't see this. Will post some examples to illustrate.

Other thing (trying to do): Mapmaster in DSN not listed in
registry. Lots of things in registry w/ no pointer to entry points, but
have a shared coord system.

AJ: Don't worry about DSN command now. Every coord sys will have a ref
server that will implement entry points and sequence.
GH: Good. Would like to change this in the doc.
GH: Doing a transitivity thing based on entries with entry points but
not coord systems, or vice versa. With proxy system you can infer
things over multiple sources.

Other things; Proxy taking das1 registry sources --> das2 sources
document, leaves all das1 capabilities in tact, so it has both das1
and das2 (a hybrid).

GH: Test deployment is sitting on Amazon cloud in Genomancer. Want it
hosted on Sanger/EBI closer to the registry, will help for
efficiency. 
JW: Can look at putting it up there. Need to look at the proxy.


Topic: Gregg's Trellis/Vine/Ivy project
===========================================

GH: Trellis project (the foundation for das1->2 proxy). Trellis is a
modular das2 server/servlet framework. Take das2 data model, plug it into
trellis to get a functional das2 server. Plan to move UCSC das2 server
to be a plugin for trellis. Framework deals with query parsing and
generating xml. Plugin is just dealing with data models.

Also das2->2 proxy as well. for das2 server that don't implement alt
content format. A proxy might be able to serve those up.  Vine module
has full das2 client library. To do a full proxy, you need a client.

Ivy: This is the das1 part of the das1->2 proxy.

Pleased with this as a framework for further development. All future das2
work will be on trellis framework. This had a larger scope than
anticipated, hence the extra time to develop.

SC: Any docs?
GH: None, other than UML.

SC: So trellis is framework. Ivy, Vine are plugins?

Noting from Gregg's DAS list post:
  * Trellis: DAS/2 server framework
  * Vine: DAS/2 proxy plugin
  * Ivy: DAS/1 proxy plugin

GH: There's a plugin API in the Trellis servlet specifying that plugin
specifies the sources capability data model, the rest of data model is
under sources. Vine=DAS2 proxy. Much impl can be obtained from that
(e.g., has stubby getters and setters). Plugin dev focus is on
capability API. 


Action Item Summary:
========================

Old action items:
-----------------

[A] Suzi: Decide Ian or Suzi is PI on grant. Issue reciprocal letters of
collab. (16-oct-08)

[A] Suzi: Summation of authentication pros and cons. Review descriptions,
make a decision. (16-oct-08)


New action items:
-----------------

[A] All: Next teleconf in two weeks: 13-Nov-08

[A] All: Anyone that has items they want discussed, send to Gregg.

[A] All: Review Gregg's DAS UML modeling, post any comments to list.

[A] All: Review Gregg's DAS1->DAS2 proxy work (Trellis/Ivy/Vine), post any
comments to list.

[A] AJ: Post info about March '09 Hinxton DAS workshop to
biodas.org/current_events

[A] AJ: Continue checking out Gregg's DAS1->DAS2 proxy, esp. the XML.

[A] GH: Send out action and agenda items well in advance of teleconf.

[A] GH: Add auth and security on the agenda so interested folks can call in.

[A] GH: Solicit feedback about security/auth from interested parties.

[A] GH: Contribute to the DAS changes document re: DAS/2, sources &
deprecating DSN.

[A] GH: Get new teleconf number from Suzi; post to list with agenda.

[A] JN: Post preliminary java web start IGB release on bioviz.org

[A] SC: Merge DAS2 subscribers to DAS list. Redirect DAS2 posts to DAS list.

[A] SC: Consider making DAS list auto reject posts from non-subsribers.

[A] SC: Add Andy J and Jonathan W as admins to the DAS mailing list.

[A] SC: Change 2 -> 2.1 and say it is "evolving"; declare the HTML spec as
"frozen"

[A] SC: Send link to the 2.1 wiki spec to list.

[A] SC: Fix Affy IGB launching links on SF page.

[A] SC: Update biodas.org community portal page with new teleconf number.



----------------------------------------------------------------------------
--------
Minutes are committed to the biodas.org CVS repository under
biodas/das/das2/notes/

$Id: das2-teleconference-2008-10-30.txt,v 1.4 2008/10/30 18:55:42 sac Exp $











From garret at globalmentor.com  Thu Oct 30 22:01:06 2008
From: garret at globalmentor.com (Garret Wilson)
Date: Thu, 30 Oct 2008 15:01:06 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>
References: <49087FF9.5080704@ebi.ac.uk>	
	<50158cb00810291044w4c26cf06w6da5dae79c0571e8@mail.gmail.com>	
	<4908B3C7.5020002@ebi.ac.uk>	
	<50158cb00810291320h5d0e0c9gd6f17ecf67c66870@mail.gmail.com>	
	<4908E705.8050904@globalmentor.com>
	<50158cb00810291639o681a9d89r97f421d15be97f9@mail.gmail.com>
Message-ID: <490A2EA2.90101@globalmentor.com>

Gregg Helt wrote:
> So let me rephrase.  Every feature in DAS/2.0 has a unique URI.  In 
> the feature XML this is represented by the "uri" attribute of the 
> FEATURE element, which is a URI reference (URI or relative URI 
> reference), and optional xml:base attributes in the document.  DAS/2.0 
> uses the XML Base specification <http://www.w3.org/TR/xmlbase/> to 
> resolve relative URI references via xml:base attributes and/or the URI 
> the document is a representation of. 

Sounds like we're all on the same page, then.

This brings up a related issue regarding the assembly and sequence URIs 
at http://www.biodas.org/wiki/GlobalSeqIDs . Before on this list I've 
brought up the issue of whether DAS has authority to maintain 
identifiers in namespaces from domains controlled by third parties (i.e. 
NCBI). This still worries me.

How confident can we be that the DAS GlobalSeqIDs are stable and will 
not change for a while?

Secondly, related to URI resolution, I note that I cannot take an 
assembly URI such as http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/ 
and simply resolve the chromosome ID (e.g. chr1) against it to form the 
sequence URI. My application instead has to have specific knowledge of 
this particular assembly namespace, knowing that it must first append 
the path segment "dna/" to the URI, yielding 
http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/dna/chr1 .

I'd rather my application, once it knew the assembly URI, simply need to 
resolve the chromosome ID to the assembly URI to determine the sequence 
URI, such as http://www.ncbi.nlm.nih.gov/genome/H_sapiens/B36.1/chr1 .

Garret


From Steve_Chervitz at affymetrix.com  Fri Oct 31 01:56:52 2008
From: Steve_Chervitz at affymetrix.com (Steve Chervitz)
Date: Thu, 30 Oct 2008 18:56:52 -0700
Subject: [DAS2] DAS/2.1 spec wiki link
Message-ID: <C52FB3F4.330CC%Steve_Chervitz@affymetrix.com>

Here's the updated link to the new wikified version of the DAS/2.1 spec, the
version that we are free to evolve toward the next version of the spec, as
we work jointly on DAS/1.x and DAS/2.x issues:

http://www.biodas.org/wiki/DAS/2.1/Spec

It's clearly distinguished from the stable 2.0 version that exists as a
static HTML document.

The only section in the 2.1 spec that has content is the retrieval portion
for genomic data:
http://www.biodas.org/wiki/DAS/2.1/Spec/Get-Genomic

Which has been split into separate wiki pages for each DAS/2 document type:
sources, segments, types, features. The other parts (stylesheet, writeback,
region locking, etc.) can be incorporated eventually.

The content of the retrieval spec was taken directly from the DAS/2.0 HTML
document, with enough edits to make it look reasonable in the wiki.  The
overview and details sections for each document type were combined on the
same page. We might want to combine the various example sections into one
(in the HTML doc, there were separate examples in the overview and details
section, which I preserved).

Have fun,
Steve

------------------------------------------------------------

This transmission is intended for the sole use of the individual
and entity to whom it is addressed, and may contain information
that is privileged, confidential and exempt from disclosure under
applicable law. You are hereby notified that any use,
dissemination, distribution or duplication of this transmission by
someone other than the intended addressee or its designated agent
is strictly prohibited. If you have received this transmission in
error, please notify the sender immediately by reply to this
transmission and delete it from your computer.


From gregghelt at gmail.com  Fri Oct 31 09:12:26 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 02:12:26 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <4909821B.6050300@nbn.ac.za>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
Message-ID: <50158cb00810310212i3a44b91ev30244955818796db@mail.gmail.com>

The DAS/2 writeback spec uses a RelaxNG schema to define the writeback XML.
The schema is at http://biodas.org/documents/das2/writeback.rnc and
references the DAS/2 retrieval spec's schema at
http://biodas.org/documents/das2/das2_schemas.rnc .  Just noticed the schema
isn't referenced in the HTML spec doc, so I've now added a link.

     Gregg

On Thu, Oct 30, 2008 at 2:44 AM, Gustavo Salazar <gustavo at nbn.ac.za> wrote:

>
> Then i am wondering if there is a DTD or XML-schema that defines those
> documents, because obviously those small changes becomes a problem during
> the parsing of the file.
>
> Cheers,
>
> Gustavo.
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>


From gregghelt at gmail.com  Fri Oct 31 11:45:38 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 04:45:38 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <49087FF9.5080704@ebi.ac.uk>
References: <49087FF9.5080704@ebi.ac.uk>
Message-ID: <50158cb00810310445x28f3aae4sa2a4b2d9955c3c82@mail.gmail.com>

All this discussion is getting me excited about writeback again!


>> 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 like that you're starting out with MyDas.  When I started work on the
DAS1-->DAS2 proxy project I reviewed the various Java-based DAS1
implementations available (including my own previous DAS1 client and server
work), and also decided to start with MyDas for the DAS1 side of the proxy.
For DAS1.53 MyDas seems to hit the sweet spot in terms of completeness
combined with low complexity.

When what was initially a DAS1-->DAS2 proxy project expanded to include a
general DAS2 server framework, DAS1 client, DAS2 client, and more, I
realized that I was really making too many fundamental changes to my copy of
MyDas and ended up redoing the DAS1 side  to use a completely new DAS1 data
model.  But even though there's no MyDas code in the proxy anymore, there's
definitely ideas from MyDas in there.

But I digress.  What I really wanted to say is that you might be able to
leverage parts of Trellis (my DAS2 server framework) and Ivy (the DAS1 proxy
plugin for Trellis) for your writeback project.  As mentioned earlier in
this thread, the DAS2 writeback spec relies on the DAS2 retrieval spec for
feature, type, etc. XML.  So if you're implementing the DAS2 writeback spec
and using MyDas on the server side, you're going to need some way of
transforming DAS2 features sent to the server in the writeback request into
the MyDas DAS1 model (or else implement a DAS2 model in MyDas).  And you'll
also need to transform DAS1 features in MyDas into DAS2 features for the
writeback response, so the transformations are bidirectional.  I think code
in Trellis and Ivy could help with these transformations.

One of the perks of Trellis is that for use with any existing Java-based
DAS1 or DAS2 server, there are several potential levels of integration.  For
DAS1 servers:

1) Separate servers: Use Trellis/Ivy as a transformational proxy server,
acts as a DAS1 client to the proxied DAS1 server.
2) Integrate by writing mapping code to transform between existing DAS1
server data model and Ivy DAS1 data model, rely on Ivy to transform from Ivy
DAS1 model to Trellis DAS2 model.
3) Integrate by writing mapping code to transform between existing DAS1
server data model and Trellis DAS2 data model.
4) Reimplement existign DAS1 server to use Trellis DAS2 data model directly.

Going down this list the level of integration with Trellis increases, and
thus so does the efficiency of the resulting DAS2 server (fewer
transformations), but the implementation overhead also increases.  So groups
that are interested in using Trellis have different options to choose from
based on their preferences/needs for implementation overhead vs. server
performance.  There's a similar list of three levels of integration for
existing DAS2 servers:

A) Separate servers: Use Trellis/Vine (Vine is the DAS2 proxy plugin for
Trellis) as a transformational proxy server, acts as a DAS2 client to the
proxied DAS2 server.
B) Integrate by writing mapping code to transform between existing DAS2
server data model and Trellis DAS2 data model
C) Reimplement existing DAS2 server to use Trellis DAS2 data model directly.

My intent is to start integrating Trellis with various DAS1 servers via (2),
and DAS2 servers via (B) and/or (C).  My short list of Trellis integration
projects, listed by estimated difficulty level:

      MyDas DAS1 server
      UCSC-based DAS2 server I've been working on
      Dazzle DAS1 server
      Genometry DAS2 server

Given that the Ivy DAS1 data model borrows ideas from MyDas, integrating
Trellis and Ivy via (2) above should be pretty straightforward.  Which would
essentially yield the MyDAS-->DAS2 half of the bidirectional transform
mentioned above for writeback implementation.  I think the DAS2-->MyDAS
other half of the transform would also fit well into the Trellis framework,
though I haven't given as much thought to that yet.

Are you interested in this approach?  If so, I'm interested in working on
this MyDAS<-->Trellis integration.  What's your timeline?  That may help
determine my project priorities over the coming months.

     Gregg


From gregghelt at gmail.com  Fri Oct 31 17:34:44 2008
From: gregghelt at gmail.com (Gregg Helt)
Date: Fri, 31 Oct 2008 10:34:44 -0700
Subject: [DAS2] [DAS] [Fwd: Re: Writeback implementation]
In-Reply-To: <490B1490.6090900@gmail.com>
References: <49087FF9.5080704@ebi.ac.uk> <4908837C.1000902@nbn.ac.za>
	<490891A4.8050908@ebi.ac.uk> <4909821B.6050300@nbn.ac.za>
	<50158cb00810310212i3a44b91ev30244955818796db@mail.gmail.com>
	<490B0CE0.5070708@nbn.ac.za> <490B1490.6090900@gmail.com>
Message-ID: <50158cb00810311034y62ecbe24yc13f77d04fd01e6d@mail.gmail.com>

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.


> Just to reinforce what you are saying about Dasty being a 1.53 client, it's
> important that we're clear about the goals of your project: to add writeback
> to DAS (as it is currently) via Dasty. This is independent of DAS/2. If
> Gregg's code can help you it of course makes sense to use it, but you do not
> have to support all of DAS/2's data model.
>

Agreed.  I don't mean to divert Gustavo's project from it's goals.  I just
wanted to point out that if the intent is to implement the current DAS/2
writeback spec that implies use of parts of the DAS/2 retrieval spec as
well.  And if the intent is also to use MyDas then that implies some
DAS1<-->DAS2 transformations will be needed, in which case the Trellis/Ivy
code base could be useful.

Reading the DAS2 writeback spec for the first time in a while I see that
there are a few bits that need to be expanded.  But I also see parts that
could be simplified.  Possibly simplified to the extent that it could become
a more generic writeback interface that requires of the XML "payload" only
that the entities to be created/edited/deleted have ids in their XML
representation, and that writeback requests/responses can inject "old_id"
and "delete" attributes/elements into those XML representations.  If we go
in that direction then I think DAS2 writeback could evolve into a more
general DAS writeback that could be used for DAS2, DAS1.53, and probably
many of the DAS extensions.

I'll try to write up a more specific proposal on this over the weekend.

    Gregg