From skoost at skoost.com  Thu Jun  4 13:16:13 2009
From: skoost at skoost.com (Ram Kumar)
Date: 4 Jun 2009 17:16:13 +0000
Subject: [DAS] A little gift - Ram
Message-ID: <20090604171503.A8D533C5C92@skoismta13.skoost.com>

Ram Kumar belongs to Skoost and sent you a little gift.

Click below to collect your gift:
http://www.skoost.com/fun?das%40lists%2Eopen%2Dbio%2Eorg/18109188/4

P.S. This is a safe and innocent gift that Ram Kumar
sent from Skoost, the free goodies website.

This e-mail was sent to das at lists.open-bio.org on 6/4/2009 6:12:09 PM
on behalf of Ram Kumar (siyasriram at gmail.com)



From gsalazar at cs.uct.ac.za  Thu Jun 11 09:09:49 2009
From: gsalazar at cs.uct.ac.za (Gustavo Salazar)
Date: Thu, 11 Jun 2009 15:09:49 +0200
Subject: [DAS] DAS writeback protocol extension
Message-ID: <4A31021D.10104@cs.uct.ac.za>

Hello all,

I have posted the first draft of my proposal for the writeback extension 
in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), please 
feel free to make any comments about it, I will really appreciate any 
feedback.

If somebody is interested, an implementation of that 
specification(source code) can be found in 
http://sourceforge.net/projects/mydaswb/ and I will setup a 
server(internet visible) in the next days for those early users who 
wants to play with that server.

Regards,

Gustavo.

From Steve_Chervitz at affymetrix.com  Thu Jun 11 13:26:59 2009
From: Steve_Chervitz at affymetrix.com (Chervitz, Steve)
Date: Thu, 11 Jun 2009 10:26:59 -0700
Subject: [DAS] DAS writeback protocol extension
In-Reply-To: <4A31021D.10104@cs.uct.ac.za>
Message-ID: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>

Gustavo,

Good to see some progress on writeback. I added a note about your implementation on the discussion page for this wiki page:

http://www.biodas.org/wiki/Talk:DAS1.6E

There is a writeback portion of the DAS2 spec that would be of useful for comparative purposes:

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

Steve


Steve Chervitz, Ph.D.
Bioinformatics Engineer, NetAffx - Informatics
Affymetrix | 6550 Vallejo St., Ste 100 | Emeryville, CA 94608
Tel: 510-428-8530 | Fax: 510-428-8585 | LinkedIn: http://is.gd/3Jeq


________________________________
From: Gustavo Salazar <gsalazar at cs.uct.ac.za>
Date: Thu, 11 Jun 2009 06:09:49 -0700
To: <das at lists.open-bio.org>
Subject: [DAS] DAS writeback protocol extension

Hello all,

I have posted the first draft of my proposal for the writeback extension
in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), please
feel free to make any comments about it, I will really appreciate any
feedback.

If somebody is interested, an implementation of that
specification(source code) can be found in
http://sourceforge.net/projects/mydaswb/ and I will setup a
server(internet visible) in the next days for those early users who
wants to play with that server.

Regards,

Gustavo.
_______________________________________________
DAS mailing list
DAS at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/das



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

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 gsalazar at cs.uct.ac.za  Fri Jun 12 04:50:13 2009
From: gsalazar at cs.uct.ac.za (Gustavo Salazar)
Date: Fri, 12 Jun 2009 10:50:13 +0200
Subject: [DAS] DAS writeback protocol extension
In-Reply-To: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>
References: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>
Message-ID: <4A3216C5.9040503@cs.uct.ac.za>

Hi Steve,
I will read the document of DAS2.1, to be honest I used a lot of the 
ideas i found in the spec for the writeback in DAS2.0 but I didn't 
notice the new info in the 2.1

Thanks,

Gustavo.

Chervitz, Steve wrote:
> Gustavo,
>
> Good to see some progress on writeback. I added a note about your 
> implementation on the discussion page for this wiki page:
>
> http://www.biodas.org/wiki/Talk:DAS1.6E
>
> There is a writeback portion of the DAS2 spec that would be of useful 
> for comparative purposes:
>
> http://www.biodas.org/wiki/DAS/2.1/Spec/Writeback
>
> Steve
>
>
> *Steve Chervitz, Ph.D.
> *Bioinformatics Engineer, NetAffx - Informatics
> Affymetrix | 6550 Vallejo St., Ste 100 | Emeryville, CA 94608
> Tel: 510-428-8530 | Fax: 510-428-8585 | LinkedIn: http://is.gd/3Jeq
>
>
> ------------------------------------------------------------------------
> *From: *Gustavo Salazar <gsalazar at cs.uct.ac.za>
> *Date: *Thu, 11 Jun 2009 06:09:49 -0700
> *To: *<das at lists.open-bio.org>
> *Subject: *[DAS] DAS writeback protocol extension
>
> Hello all,
>
> I have posted the first draft of my proposal for the writeback extension
> in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), 
> <http://www.biodas.org/wiki/DAS1.6E%29,> please
> feel free to make any comments about it, I will really appreciate any
> feedback.
>
> If somebody is interested, an implementation of that
> specification(source code) can be found in
> http://sourceforge.net/projects/mydaswb/ and I will setup a
> server(internet visible) in the next days for those early users who
> wants to play with that server.
>
> Regards,
>
> Gustavo.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>
> 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 Jun 17 11:48:24 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 17 Jun 2009 16:48:24 +0100
Subject: [DAS] Registry: forced compliance with validation and relaxng for
	newly registered servers and servers that are edited.
Message-ID: <4EB14974-2196-4DCF-873B-3E6CF724DC21@sanger.ac.uk>

There have been some registry updates recently and amongst the changes  
I just wanted to highlight:
* forced compliance with validation and relaxng for newly registered  
servers and servers that are edited.
This means that if a source owner goes to the registry and edits a  
source it will not allow the change until the registry thinks the  
source meets the 1.5 specification.
If you add a new source it must also comply with the 1.5 specification.

You can check if your source is valid by the new criterion using the  
green tick next to your source as always and some error messages will  
be displayed below if it is not valid. Ideally if owners could update  
their source to conform more to the spec that would be great. In most  
cases the changes needed to conform would be small but will help  
greatly with the interoperability of the DAS system and allow the  
system to fulfill its potential. Sources that are no longer considered  
valid will likely be removed from the registry in a couple of months  
if they have not been updated.

Some other changes that may be of interest:

* changed ontology validation to check current ontologies using EBI  
web service
* added support for validating servers for up and coming 1.6 spec (for  
development of servers only).



Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 andy.jenkinson at ebi.ac.uk  Sun Jun 28 10:57:35 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Sun, 28 Jun 2009 15:57:35 +0100
Subject: [DAS] DAS 1.6 draft 2
Message-ID: <08EE3148-0B1D-4F89-800F-CC600C4F8A21@ebi.ac.uk>

Hi all,

Having had no objections to anything in the first draft, I have posted  
draft 2 of the 1.6 spec:
http://www.ebi.ac.uk/~aj/1.6_draft2/documents/spec.html

Mostly this comprises clarifications and fixes (e.g. a diagram for  
exception handling) but there is one clarification I would like  
feedback on - HTTP status codes. Apologies for the lengthy explanation  
below...

DAS 1.53 already specifies the X-DAS-Status header to describe DAS  
error conditions, but does not say how these relate to HTTP status  
codes. The issue is confused because some of the X-DAS-Status codes  
chosen match "equivalent" HTTP statuses (e.g. 400 bad request == 400  
bad DAS command) while others do not (401 unauthorized == 401 bad  
dsn). Until fairly recently ProServer actually put the X-DAS-Status  
codes as HTTP status codes, but I changed this behaviour as it can  
result in misleading error reporting by clients.

When I came to clarify how DAS status co-exists with HTTP status for  
1.6, I realised that it is open to interpretation. One view is that  
HTTP statuses describe -only- the transport layer, and as such you  
always use HTTP 200 OK unless there is a problem in the transport  
layer. The HTTP spec thus retains its meaning. A second view is that  
the meaning of the HTTP codes can be changed as we don't use the HTTP  
features that rely on them (mainly authentication). A third view is  
that DAS statuses should be seen as more descriptive versions of  
existing HTTP statuses (e.g. 401 bad dsn is a more descriptive version  
of 400 bad request). The 400 and 500 statuses as described in the HTTP  
spec do not preclude this interpretation.

To speak for what ProServer does, it used to take the second view, and  
now takes the first view. I am wondering whether a middle-ground (the  
third view) strikes a better balance between compatibility with old  
DAS clients (which don't check X-DAS-Status) and HTTP (which requires  
401 unauthorized etc).

Please let me know what you think about the approach taken in the draft.

Cheers,
Andy

From jw12 at sanger.ac.uk  Mon Jun 29 05:31:04 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 10:31:04 +0100
Subject: [DAS] next "feature" for 1.6 spec
Message-ID: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>

Another feature we would like to add to the current 1.6 spec is the  
ability for a server to return the next feature both left and right of  
the current region if they exist but are out the currently selected  
range.
This would not need a new command, but will be specified in the spec  
as a valid response to the features cmd.

so if a user specifies chr1:1000,2000 the server can return something  
like this:
<SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label">
//minimal information about the next feature in a minimal feature  
element to include location so the client knows where the next region  
of interest for this das source is.
//if the current region has no features showing then these features  
can be returned, but as they are outside the asked for range of the  
client they will not be displayed (but can be used to have a next left  
or next right button on the client.
<FEATURE id="id">
//NEXTLEFT as the type id rather than what the type id would be if in  
the normal region.
          <TYPE id="NEXTLEFT" >type label</TYPE>
          <START> 20 </START>
          <END> 30</END>
       </FEATURE>
<FEATURE id="id">
          <TYPE id="NEXTRIGHT" >type label</TYPE>
          <START> 3000</START>
          <END> 3050 </END>
       </FEATURE>
//the rest of the response as normal if features for this region exist
       <FEATURE id="id" label="label">
          <TYPE id="id" category="category" reference="yes|no"  
cvId="SO:1234">type label</TYPE>
          <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
          <START> start </START>
          <END> end </END>
          <SCORE> [X.XX|-] </SCORE>
          <ORIENTATION> [0|-|+] </ORIENTATION>
          <PHASE> [0|1|2|-]</PHASE>
          <NOTE> note text </NOTE>
          <LINK href="url"> link text </LINK>
          <TARGET id="id" start="x" stop="y"> target name </TARGET>
          <PART id="child id1" />
          <PART id="child id2" />
       </FEATURE>
       <FEATURE id="child id1" label="child label">
          ...
       </FEATURE>
       <FEATURE id="child id2" label="child label">
          ...
       </FEATURE>
       ...
   </SEGMENT>



This ability would be an optional one, but we at the sanger, EBI  and  
Lincoln are very keen on this and see a great need and demand for it.  
It's especially useful for when there are no features returned for a  
region, for sparse data sources and for testing DAS sources in  
clients. There maybe a performance hit to implement this by the server  
and this is another reason why this response would be optional.

What do other people think?

Cheers

Jonathan.


Jonathan Warren
Senior Developer and DAS coordinator for the Sanger
jw12 at sanger.ac.uk








-- 
 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 lincoln.stein at gmail.com  Mon Jun 29 09:44:00 2009
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Mon, 29 Jun 2009 09:44:00 -0400
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
Message-ID: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>

The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if there are
no conventional features in the <SEGMENT>.

There is an ambiguity here. It is completely possible for a DAS server to
return multiple distinct feature types per segment. However, a type
"NEXTLEFT" does not distinguish which feature type can be found to the left.
Is the intent here to say that "any" feature can be found to the left or the
right?

Lincoln

On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren <jw12 at sanger.ac.uk> wrote:

> Another feature we would like to add to the current 1.6 spec is the ability
> for a server to return the next feature both left and right of the current
> region if they exist but are out the currently selected range.
> This would not need a new command, but will be specified in the spec as a
> valid response to the features cmd.
>
> so if a user specifies chr1:1000,2000 the server can return something like
> this:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label">
> //minimal information about the next feature in a minimal feature element
> to include location so the client knows where the next region of interest
> for this das source is.
> //if the current region has no features showing then these features can be
> returned, but as they are outside the asked for range of the client they
> will not be displayed (but can be used to have a next left or next right
> button on the client.
> <FEATURE id="id">
> //NEXTLEFT as the type id rather than what the type id would be if in the
> normal region.
>         <TYPE id="NEXTLEFT" >type label</TYPE>
>         <START> 20 </START>
>         <END> 30</END>
>      </FEATURE>
> <FEATURE id="id">
>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>         <START> 3000</START>
>         <END> 3050 </END>
>      </FEATURE>
> //the rest of the response as normal if features for this region exist
>      <FEATURE id="id" label="label">
>         <TYPE id="id" category="category" reference="yes|no"
> cvId="SO:1234">type label</TYPE>
>         <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>         <START> start </START>
>         <END> end </END>
>         <SCORE> [X.XX|-] </SCORE>
>         <ORIENTATION> [0|-|+] </ORIENTATION>
>         <PHASE> [0|1|2|-]</PHASE>
>         <NOTE> note text </NOTE>
>         <LINK href="url"> link text </LINK>
>         <TARGET id="id" start="x" stop="y"> target name </TARGET>
>         <PART id="child id1" />
>         <PART id="child id2" />
>      </FEATURE>
>      <FEATURE id="child id1" label="child label">
>         ...
>      </FEATURE>
>      <FEATURE id="child id2" label="child label">
>         ...
>      </FEATURE>
>      ...
>  </SEGMENT>
>
>
>
> This ability would be an optional one, but we at the sanger, EBI  and
> Lincoln are very keen on this and see a great need and demand for it. It's
> especially useful for when there are no features returned for a region, for
> sparse data sources and for testing DAS sources in clients. There maybe a
> performance hit to implement this by the server and this is another reason
> why this response would be optional.
>
> What do other people think?
>
> Cheers
>
> Jonathan.
>
>
> Jonathan Warren
> Senior Developer and DAS coordinator for the Sanger
> jw12 at sanger.ac.uk
>
>
>
>
>
>
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited,
> a charity registered in England with number 1021457 and acompany registered
> in England with number 2742969, whose registeredoffice is 215 Euston Road,
> London, NW1 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>



-- 
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Renata Musa <Renata.Musa at oicr.on.ca>

From bgel at lsi.upc.edu  Mon Jun 29 09:31:33 2009
From: bgel at lsi.upc.edu (bgel at lsi.upc.edu)
Date: Mon, 29 Jun 2009 15:31:33 +0200 (CEST)
Subject: [DAS] next "feature" for 1.6 spec
Message-ID: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>




Hi ,
I think it would be a very nice feature, at least from
the client point of view. Since it would be optional, I think it would
be interesting to have some indication wheter it is supported by a
server or not. I know a single features query for a single base would
suffuc for these, but maybe a flag on the registry and a note on the
capabilities header would be interesting. Expanding the server
metainformation is good for clients.

Bernat


> Another feature we would like to add to the current 1.6 spec is
the
> ability for a server to return the next feature both left
and right of
> the current region if they exist but are out the
currently selected
> range.
> This would not need a new
command, but will be specified in the spec
> as a valid response
to the features cmd.
> 
> so if a user specifies
chr1:1000,2000 the server can return something
> like this:
> <SEGMENT id="id" start="start"
stop="stop" version="X.XX"
label="label">
> //minimal information about the next
feature in a minimal feature
> element to include location so the
client knows where the next region
> of interest for this das
source is.
> //if the current region has no features showing then
these features
> can be returned, but as they are outside the
asked for range of the
> client they will not be displayed (but
can be used to have a next left
> or next right button on the
client.
> <FEATURE id="id">
> //NEXTLEFT
as the type id rather than what the type id would be if in
> the
normal region.
>           <TYPE id="NEXTLEFT"
>type label</TYPE>
>           <START> 20
</START>
>           <END> 30</END>
>   
    </FEATURE>
> <FEATURE id="id">
>
          <TYPE id="NEXTRIGHT" >type label</TYPE>
>           <START> 3000</START>
>          
<END> 3050 </END>
>        </FEATURE>
>
//the rest of the response as normal if features for this region exist
>        <FEATURE id="id" label="label">
>           <TYPE id="id" category="category"
reference="yes|no"
> cvId="SO:1234">type
label</TYPE>
>           <METHOD id="id"
cvId="ECO:5678"> method label </METHOD>
>      
    <START> start </START>
>           <END> end
</END>
>           <SCORE> [X.XX|-] </SCORE>
>           <ORIENTATION> [0|-|+] </ORIENTATION>
>           <PHASE> [0|1|2|-]</PHASE>
>          
<NOTE> note text </NOTE>
>           <LINK
href="url"> link text </LINK>
>          
<TARGET id="id" start="x" stop="y">
target name </TARGET>
>           <PART id="child
id1" />
>           <PART id="child id2"
/>
>        </FEATURE>
>        <FEATURE
id="child id1" label="child label">
>      
    ...
>        </FEATURE>
>        <FEATURE
id="child id2" label="child label">
>      
    ...
>        </FEATURE>
>        ...
>  
 </SEGMENT>
> 
> 
> 
> This ability
would be an optional one, but we at the sanger, EBI  and
> Lincoln
are very keen on this and see a great need and demand for it.
>
It's especially useful for when there are no features returned for a
> region, for sparse data sources and for testing DAS sources in
> clients. There maybe a performance hit to implement this by the
server
> and this is another reason why this response would be
optional.
> 
> What do other people think?
> 
> Cheers
> 
> Jonathan.
> 
> 
> Jonathan Warren
> Senior
Developer and DAS coordinator
for the Sanger
> jw12 at sanger.ac.uk
> 
> 
>

> 
> 
> 
> 
> 
> --
>  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.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
>
http://lists.open-bio.org/mailman/listinfo/das
> 

From jw12 at sanger.ac.uk  Mon Jun 29 10:34:26 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 15:34:26 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
Message-ID: <C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>

Yes that was the intent. I guess if a client is filtering on feature  
type then the way we have suggested is not going to be very useful -  
the client would have to walk along the source until it found a  
feature of the type it wants ( using the nextleft every time and  
looking at the region).

Perhaps a better way is not have any "next" flag at all as the  
segments location will show it's out of range and to the left so this  
should be obvious. This way a client can filter on type of feature in  
the normal features command and the server can return a type  
appropriate to that filter?

On 29 Jun 2009, at 14:44, Lincoln Stein wrote:

> The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if  
> there are no conventional features in the <SEGMENT>.
>
> There is an ambiguity here. It is completely possible for a DAS  
> server to return multiple distinct feature types per segment.  
> However, a type "NEXTLEFT" does not distinguish which feature type  
> can be found to the left. Is the intent here to say that "any"  
> feature can be found to the left or the right?
>
> Lincoln
>
> On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren <jw12 at sanger.ac.uk>  
> wrote:
> Another feature we would like to add to the current 1.6 spec is the  
> ability for a server to return the next feature both left and right  
> of the current region if they exist but are out the currently  
> selected range.
> This would not need a new command, but will be specified in the spec  
> as a valid response to the features cmd.
>
> so if a user specifies chr1:1000,2000 the server can return  
> something like this:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
> label="label">
> //minimal information about the next feature in a minimal feature  
> element to include location so the client knows where the next  
> region of interest for this das source is.
> //if the current region has no features showing then these features  
> can be returned, but as they are outside the asked for range of the  
> client they will not be displayed (but can be used to have a next  
> left or next right button on the client.
> <FEATURE id="id">
> //NEXTLEFT as the type id rather than what the type id would be if  
> in the normal region.
>         <TYPE id="NEXTLEFT" >type label</TYPE>
>         <START> 20 </START>
>         <END> 30</END>
>      </FEATURE>
> <FEATURE id="id">
>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>         <START> 3000</START>
>         <END> 3050 </END>
>      </FEATURE>
> //the rest of the response as normal if features for this region exist
>      <FEATURE id="id" label="label">
>         <TYPE id="id" category="category" reference="yes|no"  
> cvId="SO:1234">type label</TYPE>
>         <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>         <START> start </START>
>         <END> end </END>
>         <SCORE> [X.XX|-] </SCORE>
>         <ORIENTATION> [0|-|+] </ORIENTATION>
>         <PHASE> [0|1|2|-]</PHASE>
>         <NOTE> note text </NOTE>
>         <LINK href="url"> link text </LINK>
>         <TARGET id="id" start="x" stop="y"> target name </TARGET>
>         <PART id="child id1" />
>         <PART id="child id2" />
>      </FEATURE>
>      <FEATURE id="child id1" label="child label">
>         ...
>      </FEATURE>
>      <FEATURE id="child id2" label="child label">
>         ...
>      </FEATURE>
>      ...
>  </SEGMENT>
>
>
>
> This ability would be an optional one, but we at the sanger, EBI   
> and Lincoln are very keen on this and see a great need and demand  
> for it. It's especially useful for when there are no features  
> returned for a region, for sparse data sources and for testing DAS  
> sources in clients. There maybe a performance hit to implement this  
> by the server and this is another reason why this response would be  
> optional.
>
> What do other people think?
>
> Cheers
>
> Jonathan.
>
>
> Jonathan Warren
> Senior Developer and DAS coordinator for the Sanger
> jw12 at sanger.ac.uk
>
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>
>
>
> -- 
> Lincoln D. Stein
> Director, Informatics and Biocomputing Platform
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314








-- 
 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 jw12 at sanger.ac.uk  Mon Jun 29 10:41:36 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 15:41:36 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
References: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
Message-ID: <DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>

Hi Bernat

Thanks for the feedback!

Yes I agree (and Andy just wrote to me with the same suggestion). An  
additional capability stated in the sources response would be useful.  
Also setting up the registry to test for these capabilities, whether  
specified in the sources response by the provider or not, is on my  
todo list ;)

On 29 Jun 2009, at 14:31, bgel at lsi.upc.edu wrote:

>
>
>
> Hi ,
> I think it would be a very nice feature, at least from
> the client point of view. Since it would be optional, I think it would
> be interesting to have some indication wheter it is supported by a
> server or not. I know a single features query for a single base would
> suffuc for these, but maybe a flag on the registry and a note on the
> capabilities header would be interesting. Expanding the server
> metainformation is good for clients.
>
> Bernat
>
>
>> Another feature we would like to add to the current 1.6 spec is
> the
>> ability for a server to return the next feature both left
> and right of
>> the current region if they exist but are out the
> currently selected
>> range.
>> This would not need a new
> command, but will be specified in the spec
>> as a valid response
> to the features cmd.
>>
>> so if a user specifies
> chr1:1000,2000 the server can return something
>> like this:
>> <SEGMENT id="id" start="start"
> stop="stop" version="X.XX"
> label="label">
>> //minimal information about the next
> feature in a minimal feature
>> element to include location so the
> client knows where the next region
>> of interest for this das
> source is.
>> //if the current region has no features showing then
> these features
>> can be returned, but as they are outside the
> asked for range of the
>> client they will not be displayed (but
> can be used to have a next left
>> or next right button on the
> client.
>> <FEATURE id="id">
>> //NEXTLEFT
> as the type id rather than what the type id would be if in
>> the
> normal region.
>>          <TYPE id="NEXTLEFT"
>> type label</TYPE>
>>          <START> 20
> </START>
>>          <END> 30</END>
>>
>    </FEATURE>
>> <FEATURE id="id">
>>
>          <TYPE id="NEXTRIGHT" >type label</TYPE>
>>          <START> 3000</START>
>>
> <END> 3050 </END>
>>       </FEATURE>
>>
> //the rest of the response as normal if features for this region exist
>>       <FEATURE id="id" label="label">
>>          <TYPE id="id" category="category"
> reference="yes|no"
>> cvId="SO:1234">type
> label</TYPE>
>>          <METHOD id="id"
> cvId="ECO:5678"> method label </METHOD>
>>
>    <START> start </START>
>>          <END> end
> </END>
>>          <SCORE> [X.XX|-] </SCORE>
>>          <ORIENTATION> [0|-|+] </ORIENTATION>
>>          <PHASE> [0|1|2|-]</PHASE>
>>
> <NOTE> note text </NOTE>
>>          <LINK
> href="url"> link text </LINK>
>>
> <TARGET id="id" start="x" stop="y">
> target name </TARGET>
>>          <PART id="child
> id1" />
>>          <PART id="child id2"
> />
>>       </FEATURE>
>>       <FEATURE
> id="child id1" label="child label">
>>
>    ...
>>       </FEATURE>
>>       <FEATURE
> id="child id2" label="child label">
>>
>    ...
>>       </FEATURE>
>>       ...
>>
> </SEGMENT>
>>
>>
>>
>> This ability
> would be an optional one, but we at the sanger, EBI  and
>> Lincoln
> are very keen on this and see a great need and demand for it.
>>
> It's especially useful for when there are no features returned for a
>> region, for sparse data sources and for testing DAS sources in
>> clients. There maybe a performance hit to implement this by the
> server
>> and this is another reason why this response would be
> optional.
>>
>> What do other people think?
>>
>> Cheers
>>
>> Jonathan.
>>
>>
>> Jonathan Warren
>> Senior
> Developer and DAS coordinator
> for the Sanger
>> jw12 at sanger.ac.uk
>>
>>
>>
>
>>
>>
>>
>>
>>
>> --
>> 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.
>> _______________________________________________
>> 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

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 andy.jenkinson at ebi.ac.uk  Mon Jun 29 12:52:23 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 29 Jun 2009 17:52:23 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>
References: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
	<DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>
Message-ID: <894C2ECA-271C-4677-A6D8-1907C25A9FC1@ebi.ac.uk>

Sorry, I meant to send it to the list.

On this topic, I would love to see clients use the capabilities  
headers/entities more, and I think this requires the registry to be  
more "aggressive" in its validation and clients to rely on the  
validation more - e.g. a fail if capabilities are supported but not  
reported by the server (and vice versa of course).

Andy

On 29 Jun 2009, at 15:41, Jonathan Warren wrote:

> Hi Bernat
>
> Thanks for the feedback!
>
> Yes I agree (and Andy just wrote to me with the same suggestion). An  
> additional capability stated in the sources response would be  
> useful. Also setting up the registry to test for these capabilities,  
> whether specified in the sources response by the provider or not, is  
> on my todo list ;)
>
> On 29 Jun 2009, at 14:31, bgel at lsi.upc.edu wrote:
>
>>
>>
>>
>> Hi ,
>> I think it would be a very nice feature, at least from
>> the client point of view. Since it would be optional, I think it  
>> would
>> be interesting to have some indication wheter it is supported by a
>> server or not. I know a single features query for a single base would
>> suffuc for these, but maybe a flag on the registry and a note on the
>> capabilities header would be interesting. Expanding the server
>> metainformation is good for clients.
>>
>> Bernat
>>
>>
>>> Another feature we would like to add to the current 1.6 spec is
>> the
>>> ability for a server to return the next feature both left
>> and right of
>>> the current region if they exist but are out the
>> currently selected
>>> range.
>>> This would not need a new
>> command, but will be specified in the spec
>>> as a valid response
>> to the features cmd.
>>>
>>> so if a user specifies
>> chr1:1000,2000 the server can return something
>>> like this:
>>> <SEGMENT id="id" start="start"
>> stop="stop" version="X.XX"
>> label="label">
>>> //minimal information about the next
>> feature in a minimal feature
>>> element to include location so the
>> client knows where the next region
>>> of interest for this das
>> source is.
>>> //if the current region has no features showing then
>> these features
>>> can be returned, but as they are outside the
>> asked for range of the
>>> client they will not be displayed (but
>> can be used to have a next left
>>> or next right button on the
>> client.
>>> <FEATURE id="id">
>>> //NEXTLEFT
>> as the type id rather than what the type id would be if in
>>> the
>> normal region.
>>>         <TYPE id="NEXTLEFT"
>>> type label</TYPE>
>>>         <START> 20
>> </START>
>>>         <END> 30</END>
>>>
>>   </FEATURE>
>>> <FEATURE id="id">
>>>
>>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>>>         <START> 3000</START>
>>>
>> <END> 3050 </END>
>>>      </FEATURE>
>>>
>> //the rest of the response as normal if features for this region  
>> exist
>>>      <FEATURE id="id" label="label">
>>>         <TYPE id="id" category="category"
>> reference="yes|no"
>>> cvId="SO:1234">type
>> label</TYPE>
>>>         <METHOD id="id"
>> cvId="ECO:5678"> method label </METHOD>
>>>
>>   <START> start </START>
>>>         <END> end
>> </END>
>>>         <SCORE> [X.XX|-] </SCORE>
>>>         <ORIENTATION> [0|-|+] </ORIENTATION>
>>>         <PHASE> [0|1|2|-]</PHASE>
>>>
>> <NOTE> note text </NOTE>
>>>         <LINK
>> href="url"> link text </LINK>
>>>
>> <TARGET id="id" start="x" stop="y">
>> target name </TARGET>
>>>         <PART id="child
>> id1" />
>>>         <PART id="child id2"
>> />
>>>      </FEATURE>
>>>      <FEATURE
>> id="child id1" label="child label">
>>>
>>   ...
>>>      </FEATURE>
>>>      <FEATURE
>> id="child id2" label="child label">
>>>
>>   ...
>>>      </FEATURE>
>>>      ...
>>>
>> </SEGMENT>
>>>
>>>
>>>
>>> This ability
>> would be an optional one, but we at the sanger, EBI  and
>>> Lincoln
>> are very keen on this and see a great need and demand for it.
>>>
>> It's especially useful for when there are no features returned for a
>>> region, for sparse data sources and for testing DAS sources in
>>> clients. There maybe a performance hit to implement this by the
>> server
>>> and this is another reason why this response would be
>> optional.
>>>
>>> What do other people think?
>>>
>>> Cheers
>>>
>>> Jonathan.
>>>
>>>
>>> Jonathan Warren
>>> Senior
>> Developer and DAS coordinator
>> for the Sanger
>>> jw12 at sanger.ac.uk
>>>
>>>
>>>
>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>> _______________________________________________
>>> 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
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das


From andy.jenkinson at ebi.ac.uk  Mon Jun 29 12:59:48 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 29 Jun 2009 17:59:48 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
	<C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>
Message-ID: <D4869DD4-2102-458A-AE3D-C4E738DC7DDE@ebi.ac.uk>

How about if the server is simply allowed to return features that  
don't overlap the queried segment range, if they declare the  
appropriate capability? They would then carry the correct type etc.  
The only question is whether a client is significantly helped by an  
explicit marking of some sort. My personal view is that it's OK  
without it.

Andy

On 29 Jun 2009, at 15:34, Jonathan Warren wrote:

> Yes that was the intent. I guess if a client is filtering on feature  
> type then the way we have suggested is not going to be very useful -  
> the client would have to walk along the source until it found a  
> feature of the type it wants ( using the nextleft every time and  
> looking at the region).
>
> Perhaps a better way is not have any "next" flag at all as the  
> segments location will show it's out of range and to the left so  
> this should be obvious. This way a client can filter on type of  
> feature in the normal features command and the server can return a  
> type appropriate to that filter?
>
> On 29 Jun 2009, at 14:44, Lincoln Stein wrote:
>
>> The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if  
>> there are no conventional features in the <SEGMENT>.
>>
>> There is an ambiguity here. It is completely possible for a DAS  
>> server to return multiple distinct feature types per segment.  
>> However, a type "NEXTLEFT" does not distinguish which feature type  
>> can be found to the left. Is the intent here to say that "any"  
>> feature can be found to the left or the right?
>>
>> Lincoln
>>
>> On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren  
>> <jw12 at sanger.ac.uk> wrote:
>> Another feature we would like to add to the current 1.6 spec is the  
>> ability for a server to return the next feature both left and right  
>> of the current region if they exist but are out the currently  
>> selected range.
>> This would not need a new command, but will be specified in the  
>> spec as a valid response to the features cmd.
>>
>> so if a user specifies chr1:1000,2000 the server can return  
>> something like this:
>> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
>> label="label">
>> //minimal information about the next feature in a minimal feature  
>> element to include location so the client knows where the next  
>> region of interest for this das source is.
>> //if the current region has no features showing then these features  
>> can be returned, but as they are outside the asked for range of the  
>> client they will not be displayed (but can be used to have a next  
>> left or next right button on the client.
>> <FEATURE id="id">
>> //NEXTLEFT as the type id rather than what the type id would be if  
>> in the normal region.
>>        <TYPE id="NEXTLEFT" >type label</TYPE>
>>        <START> 20 </START>
>>        <END> 30</END>
>>     </FEATURE>
>> <FEATURE id="id">
>>        <TYPE id="NEXTRIGHT" >type label</TYPE>
>>        <START> 3000</START>
>>        <END> 3050 </END>
>>     </FEATURE>
>> //the rest of the response as normal if features for this region  
>> exist
>>     <FEATURE id="id" label="label">
>>        <TYPE id="id" category="category" reference="yes|no"  
>> cvId="SO:1234">type label</TYPE>
>>        <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>>        <START> start </START>
>>        <END> end </END>
>>        <SCORE> [X.XX|-] </SCORE>
>>        <ORIENTATION> [0|-|+] </ORIENTATION>
>>        <PHASE> [0|1|2|-]</PHASE>
>>        <NOTE> note text </NOTE>
>>        <LINK href="url"> link text </LINK>
>>        <TARGET id="id" start="x" stop="y"> target name </TARGET>
>>        <PART id="child id1" />
>>        <PART id="child id2" />
>>     </FEATURE>
>>     <FEATURE id="child id1" label="child label">
>>        ...
>>     </FEATURE>
>>     <FEATURE id="child id2" label="child label">
>>        ...
>>     </FEATURE>
>>     ...
>> </SEGMENT>
>>
>>
>>
>> This ability would be an optional one, but we at the sanger, EBI   
>> and Lincoln are very keen on this and see a great need and demand  
>> for it. It's especially useful for when there are no features  
>> returned for a region, for sparse data sources and for testing DAS  
>> sources in clients. There maybe a performance hit to implement this  
>> by the server and this is another reason why this response would be  
>> optional.
>>
>> What do other people think?
>>
>> Cheers
>>
>> Jonathan.
>>
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator for the Sanger
>> jw12 at sanger.ac.uk
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> The Wellcome Trust Sanger Institute is operated by Genome  
>> ResearchLimited, a charity registered in England with number  
>> 1021457 and acompany registered in England with number 2742969,  
>> whose registeredoffice is 215 Euston Road, London, NW1  
>> 2BE._______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>>
>>
>>
>> -- 
>> Lincoln D. Stein
>> Director, Informatics and Biocomputing Platform
>> Ontario Institute for Cancer Research
>> 101 College St., Suite 800
>> Toronto, ON, Canada M5G0A3
>> 416 673-8514
>> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das


From david.sherman at labri.fr  Mon Jun 29 15:00:27 2009
From: david.sherman at labri.fr (David Sherman)
Date: Mon, 29 Jun 2009 21:00:27 +0200
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
Message-ID: <500EE14A-41FA-4BF9-BD67-412275980E15@labri.fr>

I'd like to de-lurk here to say that this would be a great addition to
the spec. Currently we get this functionality on the client side by
sending a series of (geometrically) widening requests to get a feature
of the desired type on either side. Even with aggressive caching there
is a price to pay.

On Jun 29, 2009, at 15:44, Lincoln Stein wrote:
> There is an ambiguity here. It is completely possible for a DAS  
> server to
> return multiple distinct feature types per segment. However, a type
> "NEXTLEFT" does not distinguish which feature type can be found to  
> the left.


This would be a problem. We use next-left and next-right for navigation
on summary pages for individual elements, and the notion of "next"  
*does*
depend on the type of element (individual gene, locus, repeat element,
etc.). Reusing the type to indicate that this feature is provided even
though it is outside of the requested segment, seems abusive to me.

I suppose you could extend the feature ontology to include a new kind of
region to wrap around the next flanking features of each kind, and a
supporting server would add them on the fly. (What would you call this,
"speculative neighborhood"?)

Cheers,

djs               David J. Sherman          (David.Sherman at INRIA.FR)
                   INRIA ?quipe Magnome,  CR INRIA Bordeaux Sud-Ouest
                   Laboratoire Bordelais de Recherche en Informatique
                   voix : +33 5 40 00 6922     fax : +33 5 40 00 6669
                   icbm : 44?48'28.2"/-00?35'47.4"/49m





From enwired at gmail.com  Mon Jun 29 15:56:01 2009
From: enwired at gmail.com (Ed)
Date: Mon, 29 Jun 2009 12:56:01 -0700
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
Message-ID: <4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>

I think this is a useful feature.  I think you should also consider and test
a variety of possible other syntax before making a decision, though.
One simple alternative is to add two new fields to the segment element:
<SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label"
extendedStart="" extendedEnd="">
Here extendedStart and extendedEnd refer to the start and end of the
maximum-sized region that you could have asked for which would have returned
the same set of features.

Another simple alternative which requires NO new syntax would be for the
SEGMENT element to use the same format as before, but to allow it to
automatically stretch the start and end coordinates and return them in the
"start" and "end" fields.

<SEGMENT id="id" start="extendedStart" stop="extendedStop" version="X.XX"
label="label">
For example, if the user requests data for the region 1000 to 5000 but the
response comes back as

<SEGMENT id="id" start="500" stop="6100" version="X.XX" label="label">
then the client would be able to know that there are no additional features
in the region from 500 to 6100.  Older clients would probably not notice
that the returned start and end were different from the requested start and
end and could work as before.

Clients which cache results could cache this as covering the whole region
500 to 6100 instead of just 1000 to 5000.

I'm not currently involved in any DAS parsing, so I'm not likely to stay in
this discussion.  I just wanted to throw in this idea.

Ed Erwin
Affymetrix.


2009/6/29 Jonathan Warren <jw12 at sanger.ac.uk>

> Another feature we would like to add to the current 1.6 spec is the ability
> for a server to return the next feature both left and right of the current
> region if they exist but are out the currently selected range.
>

From jw12 at sanger.ac.uk  Tue Jun 30 12:52:37 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Tue, 30 Jun 2009 17:52:37 +0100
Subject: [DAS] Registry Version 2.3
Message-ID: <3CEF4131-7A17-4B1E-80F3-B236B3C4A81D@sanger.ac.uk>

Version 2.3 of the registry has been released.

This version shows the valid capabilities (rather than stated) of a  
server using a traffic light system in the list servers page (thanks  
Rafael Jimenez for the suggestion).
-work will start on making this information available to DAS clients  
soon.

The hourly validation mechanism now uses the relaxng validation  
schemas to test for validity. This means some people will get emails  
in the next couple of days if their sources are not valid by the new  
standards and a month or so later will be removed from the registry if  
still not valid (as per my previous email sent a couple of weeks ago).  
The error messages will hopefully be useful from the validation page  
results.

Any questions don't hesitate to ask.

Jonathan.






Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 jw12 at sanger.ac.uk  Tue Jun 30 12:56:21 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Tue, 30 Jun 2009 17:56:21 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>
Message-ID: <4AA3C244-B43C-40B7-93A2-13FF4D786637@sanger.ac.uk>

Thanks for all the great replies on this. I'm amazed at the different  
solutions people have come up with.

For now I suggest people have a play with the different suggestions  
and we can come back to this later this month and come up with a  
definitive solution.

Thanks

Jonathan.


On 29 Jun 2009, at 20:56, Ed wrote:

> I think this is a useful feature.  I think you should also consider  
> and test a variety of possible other syntax before making a  
> decision, though.
> One simple alternative is to add two new fields to the segment  
> element:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
> label="label" extendedStart="" extendedEnd="">
> Here extendedStart and extendedEnd refer to the start and end of the  
> maximum-sized region that you could have asked for which would have  
> returned the same set of features.
>
> Another simple alternative which requires NO new syntax would be for  
> the SEGMENT element to use the same format as before, but to allow  
> it to automatically stretch the start and end coordinates and return  
> them in the "start" and "end" fields.
>
> <SEGMENT id="id" start="extendedStart" stop="extendedStop"  
> version="X.XX" label="label">
> For example, if the user requests data for the region 1000 to 5000  
> but the response comes back as
>
> <SEGMENT id="id" start="500" stop="6100" version="X.XX" label="label">
> then the client would be able to know that there are no additional  
> features in the region from 500 to 6100.  Older clients would  
> probably not notice that the returned start and end were different  
> from the requested start and end and could work as before.
>
> Clients which cache results could cache this as covering the whole  
> region 500 to 6100 instead of just 1000 to 5000.
>
> I'm not currently involved in any DAS parsing, so I'm not likely to  
> stay in this discussion.  I just wanted to throw in this idea.
>
> Ed Erwin
> Affymetrix.
>
>
> 2009/6/29 Jonathan Warren <jw12 at sanger.ac.uk>
> Another feature we would like to add to the current 1.6 spec is the  
> ability for a server to return the next feature both left and right  
> of the current region if they exist but are out the currently  
> selected range.

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314








-- 
 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 skoost at skoost.com  Thu Jun  4 17:16:13 2009
From: skoost at skoost.com (Ram Kumar)
Date: 4 Jun 2009 17:16:13 +0000
Subject: [DAS] A little gift - Ram
Message-ID: <20090604171503.A8D533C5C92@skoismta13.skoost.com>

Ram Kumar belongs to Skoost and sent you a little gift.

Click below to collect your gift:
http://www.skoost.com/fun?das%40lists%2Eopen%2Dbio%2Eorg/18109188/4

P.S. This is a safe and innocent gift that Ram Kumar
sent from Skoost, the free goodies website.

This e-mail was sent to das at lists.open-bio.org on 6/4/2009 6:12:09 PM
on behalf of Ram Kumar (siyasriram at gmail.com)




From gsalazar at cs.uct.ac.za  Thu Jun 11 13:09:49 2009
From: gsalazar at cs.uct.ac.za (Gustavo Salazar)
Date: Thu, 11 Jun 2009 15:09:49 +0200
Subject: [DAS] DAS writeback protocol extension
Message-ID: <4A31021D.10104@cs.uct.ac.za>

Hello all,

I have posted the first draft of my proposal for the writeback extension 
in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), please 
feel free to make any comments about it, I will really appreciate any 
feedback.

If somebody is interested, an implementation of that 
specification(source code) can be found in 
http://sourceforge.net/projects/mydaswb/ and I will setup a 
server(internet visible) in the next days for those early users who 
wants to play with that server.

Regards,

Gustavo.


From Steve_Chervitz at affymetrix.com  Thu Jun 11 17:26:59 2009
From: Steve_Chervitz at affymetrix.com (Chervitz, Steve)
Date: Thu, 11 Jun 2009 10:26:59 -0700
Subject: [DAS] DAS writeback protocol extension
In-Reply-To: <4A31021D.10104@cs.uct.ac.za>
Message-ID: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>

Gustavo,

Good to see some progress on writeback. I added a note about your implementation on the discussion page for this wiki page:

http://www.biodas.org/wiki/Talk:DAS1.6E

There is a writeback portion of the DAS2 spec that would be of useful for comparative purposes:

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

Steve


Steve Chervitz, Ph.D.
Bioinformatics Engineer, NetAffx - Informatics
Affymetrix | 6550 Vallejo St., Ste 100 | Emeryville, CA 94608
Tel: 510-428-8530 | Fax: 510-428-8585 | LinkedIn: http://is.gd/3Jeq


________________________________
From: Gustavo Salazar <gsalazar at cs.uct.ac.za>
Date: Thu, 11 Jun 2009 06:09:49 -0700
To: <das at lists.open-bio.org>
Subject: [DAS] DAS writeback protocol extension

Hello all,

I have posted the first draft of my proposal for the writeback extension
in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), please
feel free to make any comments about it, I will really appreciate any
feedback.

If somebody is interested, an implementation of that
specification(source code) can be found in
http://sourceforge.net/projects/mydaswb/ and I will setup a
server(internet visible) in the next days for those early users who
wants to play with that server.

Regards,

Gustavo.
_______________________________________________
DAS mailing list
DAS at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/das



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

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 gsalazar at cs.uct.ac.za  Fri Jun 12 08:50:13 2009
From: gsalazar at cs.uct.ac.za (Gustavo Salazar)
Date: Fri, 12 Jun 2009 10:50:13 +0200
Subject: [DAS] DAS writeback protocol extension
In-Reply-To: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>
References: <C6568C73.3719F%Steve_Chervitz@affymetrix.com>
Message-ID: <4A3216C5.9040503@cs.uct.ac.za>

Hi Steve,
I will read the document of DAS2.1, to be honest I used a lot of the 
ideas i found in the spec for the writeback in DAS2.0 but I didn't 
notice the new info in the 2.1

Thanks,

Gustavo.

Chervitz, Steve wrote:
> Gustavo,
>
> Good to see some progress on writeback. I added a note about your 
> implementation on the discussion page for this wiki page:
>
> http://www.biodas.org/wiki/Talk:DAS1.6E
>
> There is a writeback portion of the DAS2 spec that would be of useful 
> for comparative purposes:
>
> http://www.biodas.org/wiki/DAS/2.1/Spec/Writeback
>
> Steve
>
>
> *Steve Chervitz, Ph.D.
> *Bioinformatics Engineer, NetAffx - Informatics
> Affymetrix | 6550 Vallejo St., Ste 100 | Emeryville, CA 94608
> Tel: 510-428-8530 | Fax: 510-428-8585 | LinkedIn: http://is.gd/3Jeq
>
>
> ------------------------------------------------------------------------
> *From: *Gustavo Salazar <gsalazar at cs.uct.ac.za>
> *Date: *Thu, 11 Jun 2009 06:09:49 -0700
> *To: *<das at lists.open-bio.org>
> *Subject: *[DAS] DAS writeback protocol extension
>
> Hello all,
>
> I have posted the first draft of my proposal for the writeback extension
> in the DAS1.6E wiki page (http://www.biodas.org/wiki/DAS1.6E), 
> <http://www.biodas.org/wiki/DAS1.6E%29,> please
> feel free to make any comments about it, I will really appreciate any
> feedback.
>
> If somebody is interested, an implementation of that
> specification(source code) can be found in
> http://sourceforge.net/projects/mydaswb/ and I will setup a
> server(internet visible) in the next days for those early users who
> wants to play with that server.
>
> Regards,
>
> Gustavo.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>
> 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 Jun 17 15:48:24 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 17 Jun 2009 16:48:24 +0100
Subject: [DAS] Registry: forced compliance with validation and relaxng for
	newly registered servers and servers that are edited.
Message-ID: <4EB14974-2196-4DCF-873B-3E6CF724DC21@sanger.ac.uk>

There have been some registry updates recently and amongst the changes  
I just wanted to highlight:
* forced compliance with validation and relaxng for newly registered  
servers and servers that are edited.
This means that if a source owner goes to the registry and edits a  
source it will not allow the change until the registry thinks the  
source meets the 1.5 specification.
If you add a new source it must also comply with the 1.5 specification.

You can check if your source is valid by the new criterion using the  
green tick next to your source as always and some error messages will  
be displayed below if it is not valid. Ideally if owners could update  
their source to conform more to the spec that would be great. In most  
cases the changes needed to conform would be small but will help  
greatly with the interoperability of the DAS system and allow the  
system to fulfill its potential. Sources that are no longer considered  
valid will likely be removed from the registry in a couple of months  
if they have not been updated.

Some other changes that may be of interest:

* changed ontology validation to check current ontologies using EBI  
web service
* added support for validating servers for up and coming 1.6 spec (for  
development of servers only).



Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 andy.jenkinson at ebi.ac.uk  Sun Jun 28 14:57:35 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Sun, 28 Jun 2009 15:57:35 +0100
Subject: [DAS] DAS 1.6 draft 2
Message-ID: <08EE3148-0B1D-4F89-800F-CC600C4F8A21@ebi.ac.uk>

Hi all,

Having had no objections to anything in the first draft, I have posted  
draft 2 of the 1.6 spec:
http://www.ebi.ac.uk/~aj/1.6_draft2/documents/spec.html

Mostly this comprises clarifications and fixes (e.g. a diagram for  
exception handling) but there is one clarification I would like  
feedback on - HTTP status codes. Apologies for the lengthy explanation  
below...

DAS 1.53 already specifies the X-DAS-Status header to describe DAS  
error conditions, but does not say how these relate to HTTP status  
codes. The issue is confused because some of the X-DAS-Status codes  
chosen match "equivalent" HTTP statuses (e.g. 400 bad request == 400  
bad DAS command) while others do not (401 unauthorized == 401 bad  
dsn). Until fairly recently ProServer actually put the X-DAS-Status  
codes as HTTP status codes, but I changed this behaviour as it can  
result in misleading error reporting by clients.

When I came to clarify how DAS status co-exists with HTTP status for  
1.6, I realised that it is open to interpretation. One view is that  
HTTP statuses describe -only- the transport layer, and as such you  
always use HTTP 200 OK unless there is a problem in the transport  
layer. The HTTP spec thus retains its meaning. A second view is that  
the meaning of the HTTP codes can be changed as we don't use the HTTP  
features that rely on them (mainly authentication). A third view is  
that DAS statuses should be seen as more descriptive versions of  
existing HTTP statuses (e.g. 401 bad dsn is a more descriptive version  
of 400 bad request). The 400 and 500 statuses as described in the HTTP  
spec do not preclude this interpretation.

To speak for what ProServer does, it used to take the second view, and  
now takes the first view. I am wondering whether a middle-ground (the  
third view) strikes a better balance between compatibility with old  
DAS clients (which don't check X-DAS-Status) and HTTP (which requires  
401 unauthorized etc).

Please let me know what you think about the approach taken in the draft.

Cheers,
Andy


From jw12 at sanger.ac.uk  Mon Jun 29 09:31:04 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 10:31:04 +0100
Subject: [DAS] next "feature" for 1.6 spec
Message-ID: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>

Another feature we would like to add to the current 1.6 spec is the  
ability for a server to return the next feature both left and right of  
the current region if they exist but are out the currently selected  
range.
This would not need a new command, but will be specified in the spec  
as a valid response to the features cmd.

so if a user specifies chr1:1000,2000 the server can return something  
like this:
<SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label">
//minimal information about the next feature in a minimal feature  
element to include location so the client knows where the next region  
of interest for this das source is.
//if the current region has no features showing then these features  
can be returned, but as they are outside the asked for range of the  
client they will not be displayed (but can be used to have a next left  
or next right button on the client.
<FEATURE id="id">
//NEXTLEFT as the type id rather than what the type id would be if in  
the normal region.
          <TYPE id="NEXTLEFT" >type label</TYPE>
          <START> 20 </START>
          <END> 30</END>
       </FEATURE>
<FEATURE id="id">
          <TYPE id="NEXTRIGHT" >type label</TYPE>
          <START> 3000</START>
          <END> 3050 </END>
       </FEATURE>
//the rest of the response as normal if features for this region exist
       <FEATURE id="id" label="label">
          <TYPE id="id" category="category" reference="yes|no"  
cvId="SO:1234">type label</TYPE>
          <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
          <START> start </START>
          <END> end </END>
          <SCORE> [X.XX|-] </SCORE>
          <ORIENTATION> [0|-|+] </ORIENTATION>
          <PHASE> [0|1|2|-]</PHASE>
          <NOTE> note text </NOTE>
          <LINK href="url"> link text </LINK>
          <TARGET id="id" start="x" stop="y"> target name </TARGET>
          <PART id="child id1" />
          <PART id="child id2" />
       </FEATURE>
       <FEATURE id="child id1" label="child label">
          ...
       </FEATURE>
       <FEATURE id="child id2" label="child label">
          ...
       </FEATURE>
       ...
   </SEGMENT>



This ability would be an optional one, but we at the sanger, EBI  and  
Lincoln are very keen on this and see a great need and demand for it.  
It's especially useful for when there are no features returned for a  
region, for sparse data sources and for testing DAS sources in  
clients. There maybe a performance hit to implement this by the server  
and this is another reason why this response would be optional.

What do other people think?

Cheers

Jonathan.


Jonathan Warren
Senior Developer and DAS coordinator for the Sanger
jw12 at sanger.ac.uk








-- 
 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 lincoln.stein at gmail.com  Mon Jun 29 13:44:00 2009
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Mon, 29 Jun 2009 09:44:00 -0400
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
Message-ID: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>

The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if there are
no conventional features in the <SEGMENT>.

There is an ambiguity here. It is completely possible for a DAS server to
return multiple distinct feature types per segment. However, a type
"NEXTLEFT" does not distinguish which feature type can be found to the left.
Is the intent here to say that "any" feature can be found to the left or the
right?

Lincoln

On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren <jw12 at sanger.ac.uk> wrote:

> Another feature we would like to add to the current 1.6 spec is the ability
> for a server to return the next feature both left and right of the current
> region if they exist but are out the currently selected range.
> This would not need a new command, but will be specified in the spec as a
> valid response to the features cmd.
>
> so if a user specifies chr1:1000,2000 the server can return something like
> this:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label">
> //minimal information about the next feature in a minimal feature element
> to include location so the client knows where the next region of interest
> for this das source is.
> //if the current region has no features showing then these features can be
> returned, but as they are outside the asked for range of the client they
> will not be displayed (but can be used to have a next left or next right
> button on the client.
> <FEATURE id="id">
> //NEXTLEFT as the type id rather than what the type id would be if in the
> normal region.
>         <TYPE id="NEXTLEFT" >type label</TYPE>
>         <START> 20 </START>
>         <END> 30</END>
>      </FEATURE>
> <FEATURE id="id">
>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>         <START> 3000</START>
>         <END> 3050 </END>
>      </FEATURE>
> //the rest of the response as normal if features for this region exist
>      <FEATURE id="id" label="label">
>         <TYPE id="id" category="category" reference="yes|no"
> cvId="SO:1234">type label</TYPE>
>         <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>         <START> start </START>
>         <END> end </END>
>         <SCORE> [X.XX|-] </SCORE>
>         <ORIENTATION> [0|-|+] </ORIENTATION>
>         <PHASE> [0|1|2|-]</PHASE>
>         <NOTE> note text </NOTE>
>         <LINK href="url"> link text </LINK>
>         <TARGET id="id" start="x" stop="y"> target name </TARGET>
>         <PART id="child id1" />
>         <PART id="child id2" />
>      </FEATURE>
>      <FEATURE id="child id1" label="child label">
>         ...
>      </FEATURE>
>      <FEATURE id="child id2" label="child label">
>         ...
>      </FEATURE>
>      ...
>  </SEGMENT>
>
>
>
> This ability would be an optional one, but we at the sanger, EBI  and
> Lincoln are very keen on this and see a great need and demand for it. It's
> especially useful for when there are no features returned for a region, for
> sparse data sources and for testing DAS sources in clients. There maybe a
> performance hit to implement this by the server and this is another reason
> why this response would be optional.
>
> What do other people think?
>
> Cheers
>
> Jonathan.
>
>
> Jonathan Warren
> Senior Developer and DAS coordinator for the Sanger
> jw12 at sanger.ac.uk
>
>
>
>
>
>
>
>
> --
> The Wellcome Trust Sanger Institute is operated by Genome ResearchLimited,
> a charity registered in England with number 1021457 and acompany registered
> in England with number 2742969, whose registeredoffice is 215 Euston Road,
> London, NW1 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>



-- 
Lincoln D. Stein
Director, Informatics and Biocomputing Platform
Ontario Institute for Cancer Research
101 College St., Suite 800
Toronto, ON, Canada M5G0A3
416 673-8514
Assistant: Renata Musa <Renata.Musa at oicr.on.ca>


From bgel at lsi.upc.edu  Mon Jun 29 13:31:33 2009
From: bgel at lsi.upc.edu (bgel at lsi.upc.edu)
Date: Mon, 29 Jun 2009 15:31:33 +0200 (CEST)
Subject: [DAS] next "feature" for 1.6 spec
Message-ID: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>




Hi ,
I think it would be a very nice feature, at least from
the client point of view. Since it would be optional, I think it would
be interesting to have some indication wheter it is supported by a
server or not. I know a single features query for a single base would
suffuc for these, but maybe a flag on the registry and a note on the
capabilities header would be interesting. Expanding the server
metainformation is good for clients.

Bernat


> Another feature we would like to add to the current 1.6 spec is
the
> ability for a server to return the next feature both left
and right of
> the current region if they exist but are out the
currently selected
> range.
> This would not need a new
command, but will be specified in the spec
> as a valid response
to the features cmd.
> 
> so if a user specifies
chr1:1000,2000 the server can return something
> like this:
> <SEGMENT id="id" start="start"
stop="stop" version="X.XX"
label="label">
> //minimal information about the next
feature in a minimal feature
> element to include location so the
client knows where the next region
> of interest for this das
source is.
> //if the current region has no features showing then
these features
> can be returned, but as they are outside the
asked for range of the
> client they will not be displayed (but
can be used to have a next left
> or next right button on the
client.
> <FEATURE id="id">
> //NEXTLEFT
as the type id rather than what the type id would be if in
> the
normal region.
>           <TYPE id="NEXTLEFT"
>type label</TYPE>
>           <START> 20
</START>
>           <END> 30</END>
>   
    </FEATURE>
> <FEATURE id="id">
>
          <TYPE id="NEXTRIGHT" >type label</TYPE>
>           <START> 3000</START>
>          
<END> 3050 </END>
>        </FEATURE>
>
//the rest of the response as normal if features for this region exist
>        <FEATURE id="id" label="label">
>           <TYPE id="id" category="category"
reference="yes|no"
> cvId="SO:1234">type
label</TYPE>
>           <METHOD id="id"
cvId="ECO:5678"> method label </METHOD>
>      
    <START> start </START>
>           <END> end
</END>
>           <SCORE> [X.XX|-] </SCORE>
>           <ORIENTATION> [0|-|+] </ORIENTATION>
>           <PHASE> [0|1|2|-]</PHASE>
>          
<NOTE> note text </NOTE>
>           <LINK
href="url"> link text </LINK>
>          
<TARGET id="id" start="x" stop="y">
target name </TARGET>
>           <PART id="child
id1" />
>           <PART id="child id2"
/>
>        </FEATURE>
>        <FEATURE
id="child id1" label="child label">
>      
    ...
>        </FEATURE>
>        <FEATURE
id="child id2" label="child label">
>      
    ...
>        </FEATURE>
>        ...
>  
 </SEGMENT>
> 
> 
> 
> This ability
would be an optional one, but we at the sanger, EBI  and
> Lincoln
are very keen on this and see a great need and demand for it.
>
It's especially useful for when there are no features returned for a
> region, for sparse data sources and for testing DAS sources in
> clients. There maybe a performance hit to implement this by the
server
> and this is another reason why this response would be
optional.
> 
> What do other people think?
> 
> Cheers
> 
> Jonathan.
> 
> 
> Jonathan Warren
> Senior
Developer and DAS coordinator
for the Sanger
> jw12 at sanger.ac.uk
> 
> 
>

> 
> 
> 
> 
> 
> --
>  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.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
>
http://lists.open-bio.org/mailman/listinfo/das
> 


From jw12 at sanger.ac.uk  Mon Jun 29 14:34:26 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 15:34:26 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
Message-ID: <C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>

Yes that was the intent. I guess if a client is filtering on feature  
type then the way we have suggested is not going to be very useful -  
the client would have to walk along the source until it found a  
feature of the type it wants ( using the nextleft every time and  
looking at the region).

Perhaps a better way is not have any "next" flag at all as the  
segments location will show it's out of range and to the left so this  
should be obvious. This way a client can filter on type of feature in  
the normal features command and the server can return a type  
appropriate to that filter?

On 29 Jun 2009, at 14:44, Lincoln Stein wrote:

> The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if  
> there are no conventional features in the <SEGMENT>.
>
> There is an ambiguity here. It is completely possible for a DAS  
> server to return multiple distinct feature types per segment.  
> However, a type "NEXTLEFT" does not distinguish which feature type  
> can be found to the left. Is the intent here to say that "any"  
> feature can be found to the left or the right?
>
> Lincoln
>
> On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren <jw12 at sanger.ac.uk>  
> wrote:
> Another feature we would like to add to the current 1.6 spec is the  
> ability for a server to return the next feature both left and right  
> of the current region if they exist but are out the currently  
> selected range.
> This would not need a new command, but will be specified in the spec  
> as a valid response to the features cmd.
>
> so if a user specifies chr1:1000,2000 the server can return  
> something like this:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
> label="label">
> //minimal information about the next feature in a minimal feature  
> element to include location so the client knows where the next  
> region of interest for this das source is.
> //if the current region has no features showing then these features  
> can be returned, but as they are outside the asked for range of the  
> client they will not be displayed (but can be used to have a next  
> left or next right button on the client.
> <FEATURE id="id">
> //NEXTLEFT as the type id rather than what the type id would be if  
> in the normal region.
>         <TYPE id="NEXTLEFT" >type label</TYPE>
>         <START> 20 </START>
>         <END> 30</END>
>      </FEATURE>
> <FEATURE id="id">
>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>         <START> 3000</START>
>         <END> 3050 </END>
>      </FEATURE>
> //the rest of the response as normal if features for this region exist
>      <FEATURE id="id" label="label">
>         <TYPE id="id" category="category" reference="yes|no"  
> cvId="SO:1234">type label</TYPE>
>         <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>         <START> start </START>
>         <END> end </END>
>         <SCORE> [X.XX|-] </SCORE>
>         <ORIENTATION> [0|-|+] </ORIENTATION>
>         <PHASE> [0|1|2|-]</PHASE>
>         <NOTE> note text </NOTE>
>         <LINK href="url"> link text </LINK>
>         <TARGET id="id" start="x" stop="y"> target name </TARGET>
>         <PART id="child id1" />
>         <PART id="child id2" />
>      </FEATURE>
>      <FEATURE id="child id1" label="child label">
>         ...
>      </FEATURE>
>      <FEATURE id="child id2" label="child label">
>         ...
>      </FEATURE>
>      ...
>  </SEGMENT>
>
>
>
> This ability would be an optional one, but we at the sanger, EBI   
> and Lincoln are very keen on this and see a great need and demand  
> for it. It's especially useful for when there are no features  
> returned for a region, for sparse data sources and for testing DAS  
> sources in clients. There maybe a performance hit to implement this  
> by the server and this is another reason why this response would be  
> optional.
>
> What do other people think?
>
> Cheers
>
> Jonathan.
>
>
> Jonathan Warren
> Senior Developer and DAS coordinator for the Sanger
> jw12 at sanger.ac.uk
>
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>
>
>
> -- 
> Lincoln D. Stein
> Director, Informatics and Biocomputing Platform
> Ontario Institute for Cancer Research
> 101 College St., Suite 800
> Toronto, ON, Canada M5G0A3
> 416 673-8514
> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314








-- 
 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 jw12 at sanger.ac.uk  Mon Jun 29 14:41:36 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 29 Jun 2009 15:41:36 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
References: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
Message-ID: <DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>

Hi Bernat

Thanks for the feedback!

Yes I agree (and Andy just wrote to me with the same suggestion). An  
additional capability stated in the sources response would be useful.  
Also setting up the registry to test for these capabilities, whether  
specified in the sources response by the provider or not, is on my  
todo list ;)

On 29 Jun 2009, at 14:31, bgel at lsi.upc.edu wrote:

>
>
>
> Hi ,
> I think it would be a very nice feature, at least from
> the client point of view. Since it would be optional, I think it would
> be interesting to have some indication wheter it is supported by a
> server or not. I know a single features query for a single base would
> suffuc for these, but maybe a flag on the registry and a note on the
> capabilities header would be interesting. Expanding the server
> metainformation is good for clients.
>
> Bernat
>
>
>> Another feature we would like to add to the current 1.6 spec is
> the
>> ability for a server to return the next feature both left
> and right of
>> the current region if they exist but are out the
> currently selected
>> range.
>> This would not need a new
> command, but will be specified in the spec
>> as a valid response
> to the features cmd.
>>
>> so if a user specifies
> chr1:1000,2000 the server can return something
>> like this:
>> <SEGMENT id="id" start="start"
> stop="stop" version="X.XX"
> label="label">
>> //minimal information about the next
> feature in a minimal feature
>> element to include location so the
> client knows where the next region
>> of interest for this das
> source is.
>> //if the current region has no features showing then
> these features
>> can be returned, but as they are outside the
> asked for range of the
>> client they will not be displayed (but
> can be used to have a next left
>> or next right button on the
> client.
>> <FEATURE id="id">
>> //NEXTLEFT
> as the type id rather than what the type id would be if in
>> the
> normal region.
>>          <TYPE id="NEXTLEFT"
>> type label</TYPE>
>>          <START> 20
> </START>
>>          <END> 30</END>
>>
>    </FEATURE>
>> <FEATURE id="id">
>>
>          <TYPE id="NEXTRIGHT" >type label</TYPE>
>>          <START> 3000</START>
>>
> <END> 3050 </END>
>>       </FEATURE>
>>
> //the rest of the response as normal if features for this region exist
>>       <FEATURE id="id" label="label">
>>          <TYPE id="id" category="category"
> reference="yes|no"
>> cvId="SO:1234">type
> label</TYPE>
>>          <METHOD id="id"
> cvId="ECO:5678"> method label </METHOD>
>>
>    <START> start </START>
>>          <END> end
> </END>
>>          <SCORE> [X.XX|-] </SCORE>
>>          <ORIENTATION> [0|-|+] </ORIENTATION>
>>          <PHASE> [0|1|2|-]</PHASE>
>>
> <NOTE> note text </NOTE>
>>          <LINK
> href="url"> link text </LINK>
>>
> <TARGET id="id" start="x" stop="y">
> target name </TARGET>
>>          <PART id="child
> id1" />
>>          <PART id="child id2"
> />
>>       </FEATURE>
>>       <FEATURE
> id="child id1" label="child label">
>>
>    ...
>>       </FEATURE>
>>       <FEATURE
> id="child id2" label="child label">
>>
>    ...
>>       </FEATURE>
>>       ...
>>
> </SEGMENT>
>>
>>
>>
>> This ability
> would be an optional one, but we at the sanger, EBI  and
>> Lincoln
> are very keen on this and see a great need and demand for it.
>>
> It's especially useful for when there are no features returned for a
>> region, for sparse data sources and for testing DAS sources in
>> clients. There maybe a performance hit to implement this by the
> server
>> and this is another reason why this response would be
> optional.
>>
>> What do other people think?
>>
>> Cheers
>>
>> Jonathan.
>>
>>
>> Jonathan Warren
>> Senior
> Developer and DAS coordinator
> for the Sanger
>> jw12 at sanger.ac.uk
>>
>>
>>
>
>>
>>
>>
>>
>>
>> --
>> 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.
>> _______________________________________________
>> 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

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 andy.jenkinson at ebi.ac.uk  Mon Jun 29 16:52:23 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 29 Jun 2009 17:52:23 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>
References: <33022.212.247.139.68.1246282293.squirrel@webmail.lsi.upc.edu>
	<DF4B08C0-10E0-4342-AB7C-002E84E63534@sanger.ac.uk>
Message-ID: <894C2ECA-271C-4677-A6D8-1907C25A9FC1@ebi.ac.uk>

Sorry, I meant to send it to the list.

On this topic, I would love to see clients use the capabilities  
headers/entities more, and I think this requires the registry to be  
more "aggressive" in its validation and clients to rely on the  
validation more - e.g. a fail if capabilities are supported but not  
reported by the server (and vice versa of course).

Andy

On 29 Jun 2009, at 15:41, Jonathan Warren wrote:

> Hi Bernat
>
> Thanks for the feedback!
>
> Yes I agree (and Andy just wrote to me with the same suggestion). An  
> additional capability stated in the sources response would be  
> useful. Also setting up the registry to test for these capabilities,  
> whether specified in the sources response by the provider or not, is  
> on my todo list ;)
>
> On 29 Jun 2009, at 14:31, bgel at lsi.upc.edu wrote:
>
>>
>>
>>
>> Hi ,
>> I think it would be a very nice feature, at least from
>> the client point of view. Since it would be optional, I think it  
>> would
>> be interesting to have some indication wheter it is supported by a
>> server or not. I know a single features query for a single base would
>> suffuc for these, but maybe a flag on the registry and a note on the
>> capabilities header would be interesting. Expanding the server
>> metainformation is good for clients.
>>
>> Bernat
>>
>>
>>> Another feature we would like to add to the current 1.6 spec is
>> the
>>> ability for a server to return the next feature both left
>> and right of
>>> the current region if they exist but are out the
>> currently selected
>>> range.
>>> This would not need a new
>> command, but will be specified in the spec
>>> as a valid response
>> to the features cmd.
>>>
>>> so if a user specifies
>> chr1:1000,2000 the server can return something
>>> like this:
>>> <SEGMENT id="id" start="start"
>> stop="stop" version="X.XX"
>> label="label">
>>> //minimal information about the next
>> feature in a minimal feature
>>> element to include location so the
>> client knows where the next region
>>> of interest for this das
>> source is.
>>> //if the current region has no features showing then
>> these features
>>> can be returned, but as they are outside the
>> asked for range of the
>>> client they will not be displayed (but
>> can be used to have a next left
>>> or next right button on the
>> client.
>>> <FEATURE id="id">
>>> //NEXTLEFT
>> as the type id rather than what the type id would be if in
>>> the
>> normal region.
>>>         <TYPE id="NEXTLEFT"
>>> type label</TYPE>
>>>         <START> 20
>> </START>
>>>         <END> 30</END>
>>>
>>   </FEATURE>
>>> <FEATURE id="id">
>>>
>>         <TYPE id="NEXTRIGHT" >type label</TYPE>
>>>         <START> 3000</START>
>>>
>> <END> 3050 </END>
>>>      </FEATURE>
>>>
>> //the rest of the response as normal if features for this region  
>> exist
>>>      <FEATURE id="id" label="label">
>>>         <TYPE id="id" category="category"
>> reference="yes|no"
>>> cvId="SO:1234">type
>> label</TYPE>
>>>         <METHOD id="id"
>> cvId="ECO:5678"> method label </METHOD>
>>>
>>   <START> start </START>
>>>         <END> end
>> </END>
>>>         <SCORE> [X.XX|-] </SCORE>
>>>         <ORIENTATION> [0|-|+] </ORIENTATION>
>>>         <PHASE> [0|1|2|-]</PHASE>
>>>
>> <NOTE> note text </NOTE>
>>>         <LINK
>> href="url"> link text </LINK>
>>>
>> <TARGET id="id" start="x" stop="y">
>> target name </TARGET>
>>>         <PART id="child
>> id1" />
>>>         <PART id="child id2"
>> />
>>>      </FEATURE>
>>>      <FEATURE
>> id="child id1" label="child label">
>>>
>>   ...
>>>      </FEATURE>
>>>      <FEATURE
>> id="child id2" label="child label">
>>>
>>   ...
>>>      </FEATURE>
>>>      ...
>>>
>> </SEGMENT>
>>>
>>>
>>>
>>> This ability
>> would be an optional one, but we at the sanger, EBI  and
>>> Lincoln
>> are very keen on this and see a great need and demand for it.
>>>
>> It's especially useful for when there are no features returned for a
>>> region, for sparse data sources and for testing DAS sources in
>>> clients. There maybe a performance hit to implement this by the
>> server
>>> and this is another reason why this response would be
>> optional.
>>>
>>> What do other people think?
>>>
>>> Cheers
>>>
>>> Jonathan.
>>>
>>>
>>> Jonathan Warren
>>> Senior
>> Developer and DAS coordinator
>> for the Sanger
>>> jw12 at sanger.ac.uk
>>>
>>>
>>>
>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>> _______________________________________________
>>> 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
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das



From andy.jenkinson at ebi.ac.uk  Mon Jun 29 16:59:48 2009
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 29 Jun 2009 17:59:48 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
	<C707C68F-0014-4415-B7C8-B907FC380F42@sanger.ac.uk>
Message-ID: <D4869DD4-2102-458A-AE3D-C4E738DC7DDE@ebi.ac.uk>

How about if the server is simply allowed to return features that  
don't overlap the queried segment range, if they declare the  
appropriate capability? They would then carry the correct type etc.  
The only question is whether a client is significantly helped by an  
explicit marking of some sort. My personal view is that it's OK  
without it.

Andy

On 29 Jun 2009, at 15:34, Jonathan Warren wrote:

> Yes that was the intent. I guess if a client is filtering on feature  
> type then the way we have suggested is not going to be very useful -  
> the client would have to walk along the source until it found a  
> feature of the type it wants ( using the nextleft every time and  
> looking at the region).
>
> Perhaps a better way is not have any "next" flag at all as the  
> segments location will show it's out of range and to the left so  
> this should be obvious. This way a client can filter on type of  
> feature in the normal features command and the server can return a  
> type appropriate to that filter?
>
> On 29 Jun 2009, at 14:44, Lincoln Stein wrote:
>
>> The NEXTLEFT and NEXTRIGHT pseudo-features should appear even if  
>> there are no conventional features in the <SEGMENT>.
>>
>> There is an ambiguity here. It is completely possible for a DAS  
>> server to return multiple distinct feature types per segment.  
>> However, a type "NEXTLEFT" does not distinguish which feature type  
>> can be found to the left. Is the intent here to say that "any"  
>> feature can be found to the left or the right?
>>
>> Lincoln
>>
>> On Mon, Jun 29, 2009 at 5:31 AM, Jonathan Warren  
>> <jw12 at sanger.ac.uk> wrote:
>> Another feature we would like to add to the current 1.6 spec is the  
>> ability for a server to return the next feature both left and right  
>> of the current region if they exist but are out the currently  
>> selected range.
>> This would not need a new command, but will be specified in the  
>> spec as a valid response to the features cmd.
>>
>> so if a user specifies chr1:1000,2000 the server can return  
>> something like this:
>> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
>> label="label">
>> //minimal information about the next feature in a minimal feature  
>> element to include location so the client knows where the next  
>> region of interest for this das source is.
>> //if the current region has no features showing then these features  
>> can be returned, but as they are outside the asked for range of the  
>> client they will not be displayed (but can be used to have a next  
>> left or next right button on the client.
>> <FEATURE id="id">
>> //NEXTLEFT as the type id rather than what the type id would be if  
>> in the normal region.
>>        <TYPE id="NEXTLEFT" >type label</TYPE>
>>        <START> 20 </START>
>>        <END> 30</END>
>>     </FEATURE>
>> <FEATURE id="id">
>>        <TYPE id="NEXTRIGHT" >type label</TYPE>
>>        <START> 3000</START>
>>        <END> 3050 </END>
>>     </FEATURE>
>> //the rest of the response as normal if features for this region  
>> exist
>>     <FEATURE id="id" label="label">
>>        <TYPE id="id" category="category" reference="yes|no"  
>> cvId="SO:1234">type label</TYPE>
>>        <METHOD id="id" cvId="ECO:5678"> method label </METHOD>
>>        <START> start </START>
>>        <END> end </END>
>>        <SCORE> [X.XX|-] </SCORE>
>>        <ORIENTATION> [0|-|+] </ORIENTATION>
>>        <PHASE> [0|1|2|-]</PHASE>
>>        <NOTE> note text </NOTE>
>>        <LINK href="url"> link text </LINK>
>>        <TARGET id="id" start="x" stop="y"> target name </TARGET>
>>        <PART id="child id1" />
>>        <PART id="child id2" />
>>     </FEATURE>
>>     <FEATURE id="child id1" label="child label">
>>        ...
>>     </FEATURE>
>>     <FEATURE id="child id2" label="child label">
>>        ...
>>     </FEATURE>
>>     ...
>> </SEGMENT>
>>
>>
>>
>> This ability would be an optional one, but we at the sanger, EBI   
>> and Lincoln are very keen on this and see a great need and demand  
>> for it. It's especially useful for when there are no features  
>> returned for a region, for sparse data sources and for testing DAS  
>> sources in clients. There maybe a performance hit to implement this  
>> by the server and this is another reason why this response would be  
>> optional.
>>
>> What do other people think?
>>
>> Cheers
>>
>> Jonathan.
>>
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator for the Sanger
>> jw12 at sanger.ac.uk
>>
>>
>>
>>
>>
>>
>>
>>
>> -- 
>> The Wellcome Trust Sanger Institute is operated by Genome  
>> ResearchLimited, a charity registered in England with number  
>> 1021457 and acompany registered in England with number 2742969,  
>> whose registeredoffice is 215 Euston Road, London, NW1  
>> 2BE._______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>>
>>
>>
>> -- 
>> Lincoln D. Stein
>> Director, Informatics and Biocomputing Platform
>> Ontario Institute for Cancer Research
>> 101 College St., Suite 800
>> Toronto, ON, Canada M5G0A3
>> 416 673-8514
>> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
>
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome  
> ResearchLimited, a charity registered in England with number 1021457  
> and acompany registered in England with number 2742969, whose  
> registeredoffice is 215 Euston Road, London, NW1  
> 2BE._______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das



From david.sherman at labri.fr  Mon Jun 29 19:00:27 2009
From: david.sherman at labri.fr (David Sherman)
Date: Mon, 29 Jun 2009 21:00:27 +0200
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<6dce9a0b0906290644n4537b0e1m866d92f3b19888dc@mail.gmail.com>
Message-ID: <500EE14A-41FA-4BF9-BD67-412275980E15@labri.fr>

I'd like to de-lurk here to say that this would be a great addition to
the spec. Currently we get this functionality on the client side by
sending a series of (geometrically) widening requests to get a feature
of the desired type on either side. Even with aggressive caching there
is a price to pay.

On Jun 29, 2009, at 15:44, Lincoln Stein wrote:
> There is an ambiguity here. It is completely possible for a DAS  
> server to
> return multiple distinct feature types per segment. However, a type
> "NEXTLEFT" does not distinguish which feature type can be found to  
> the left.


This would be a problem. We use next-left and next-right for navigation
on summary pages for individual elements, and the notion of "next"  
*does*
depend on the type of element (individual gene, locus, repeat element,
etc.). Reusing the type to indicate that this feature is provided even
though it is outside of the requested segment, seems abusive to me.

I suppose you could extend the feature ontology to include a new kind of
region to wrap around the next flanking features of each kind, and a
supporting server would add them on the fly. (What would you call this,
"speculative neighborhood"?)

Cheers,

djs               David J. Sherman          (David.Sherman at INRIA.FR)
                   INRIA ?quipe Magnome,  CR INRIA Bordeaux Sud-Ouest
                   Laboratoire Bordelais de Recherche en Informatique
                   voix : +33 5 40 00 6922     fax : +33 5 40 00 6669
                   icbm : 44?48'28.2"/-00?35'47.4"/49m






From enwired at gmail.com  Mon Jun 29 19:56:01 2009
From: enwired at gmail.com (Ed)
Date: Mon, 29 Jun 2009 12:56:01 -0700
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
Message-ID: <4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>

I think this is a useful feature.  I think you should also consider and test
a variety of possible other syntax before making a decision, though.
One simple alternative is to add two new fields to the segment element:
<SEGMENT id="id" start="start" stop="stop" version="X.XX" label="label"
extendedStart="" extendedEnd="">
Here extendedStart and extendedEnd refer to the start and end of the
maximum-sized region that you could have asked for which would have returned
the same set of features.

Another simple alternative which requires NO new syntax would be for the
SEGMENT element to use the same format as before, but to allow it to
automatically stretch the start and end coordinates and return them in the
"start" and "end" fields.

<SEGMENT id="id" start="extendedStart" stop="extendedStop" version="X.XX"
label="label">
For example, if the user requests data for the region 1000 to 5000 but the
response comes back as

<SEGMENT id="id" start="500" stop="6100" version="X.XX" label="label">
then the client would be able to know that there are no additional features
in the region from 500 to 6100.  Older clients would probably not notice
that the returned start and end were different from the requested start and
end and could work as before.

Clients which cache results could cache this as covering the whole region
500 to 6100 instead of just 1000 to 5000.

I'm not currently involved in any DAS parsing, so I'm not likely to stay in
this discussion.  I just wanted to throw in this idea.

Ed Erwin
Affymetrix.


2009/6/29 Jonathan Warren <jw12 at sanger.ac.uk>

> Another feature we would like to add to the current 1.6 spec is the ability
> for a server to return the next feature both left and right of the current
> region if they exist but are out the currently selected range.
>


From jw12 at sanger.ac.uk  Tue Jun 30 16:52:37 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Tue, 30 Jun 2009 17:52:37 +0100
Subject: [DAS] Registry Version 2.3
Message-ID: <3CEF4131-7A17-4B1E-80F3-B236B3C4A81D@sanger.ac.uk>

Version 2.3 of the registry has been released.

This version shows the valid capabilities (rather than stated) of a  
server using a traffic light system in the list servers page (thanks  
Rafael Jimenez for the suggestion).
-work will start on making this information available to DAS clients  
soon.

The hourly validation mechanism now uses the relaxng validation  
schemas to test for validity. This means some people will get emails  
in the next couple of days if their sources are not valid by the new  
standards and a month or so later will be removed from the registry if  
still not valid (as per my previous email sent a couple of weeks ago).  
The error messages will hopefully be useful from the validation page  
results.

Any questions don't hesitate to ask.

Jonathan.






Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314







-- 
 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 jw12 at sanger.ac.uk  Tue Jun 30 16:56:21 2009
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Tue, 30 Jun 2009 17:56:21 +0100
Subject: [DAS] next "feature" for 1.6 spec
In-Reply-To: <4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>
References: <80309491-46EF-48CC-80D0-F68F69095B07@sanger.ac.uk>
	<4aa3a7e70906291256q63c2e288xfab331ed82cac6d4@mail.gmail.com>
Message-ID: <4AA3C244-B43C-40B7-93A2-13FF4D786637@sanger.ac.uk>

Thanks for all the great replies on this. I'm amazed at the different  
solutions people have come up with.

For now I suggest people have a play with the different suggestions  
and we can come back to this later this month and come up with a  
definitive solution.

Thanks

Jonathan.


On 29 Jun 2009, at 20:56, Ed wrote:

> I think this is a useful feature.  I think you should also consider  
> and test a variety of possible other syntax before making a  
> decision, though.
> One simple alternative is to add two new fields to the segment  
> element:
> <SEGMENT id="id" start="start" stop="stop" version="X.XX"  
> label="label" extendedStart="" extendedEnd="">
> Here extendedStart and extendedEnd refer to the start and end of the  
> maximum-sized region that you could have asked for which would have  
> returned the same set of features.
>
> Another simple alternative which requires NO new syntax would be for  
> the SEGMENT element to use the same format as before, but to allow  
> it to automatically stretch the start and end coordinates and return  
> them in the "start" and "end" fields.
>
> <SEGMENT id="id" start="extendedStart" stop="extendedStop"  
> version="X.XX" label="label">
> For example, if the user requests data for the region 1000 to 5000  
> but the response comes back as
>
> <SEGMENT id="id" start="500" stop="6100" version="X.XX" label="label">
> then the client would be able to know that there are no additional  
> features in the region from 500 to 6100.  Older clients would  
> probably not notice that the returned start and end were different  
> from the requested start and end and could work as before.
>
> Clients which cache results could cache this as covering the whole  
> region 500 to 6100 instead of just 1000 to 5000.
>
> I'm not currently involved in any DAS parsing, so I'm not likely to  
> stay in this discussion.  I just wanted to throw in this idea.
>
> Ed Erwin
> Affymetrix.
>
>
> 2009/6/29 Jonathan Warren <jw12 at sanger.ac.uk>
> Another feature we would like to add to the current 1.6 spec is the  
> ability for a server to return the next feature both left and right  
> of the current region if they exist but are out the currently  
> selected range.

Jonathan Warren
Senior Developer and DAS coordinator
jw12 at sanger.ac.uk
Ext: 2314
Telephone: 01223 492314








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