From rmb32 at cornell.edu Sun Aug 1 15:17:14 2010
From: rmb32 at cornell.edu (Robert Buels)
Date: Sun, 01 Aug 2010 12:17:14 -0700
Subject: [DAS] GMOD Evo Hackathon Open Call for Participation
Message-ID: <4C55C83A.3060700@cornell.edu>
We are seeking participants for the GMOD Tools for Evolutionary Biology
Hackathon, held November 8-12, 2010 at the US National Evolutionary
Synthesis Center (NESCent) in Durham, NC.
This hackathon targets three critical gaps in the capabilities of the
GMOD toolbox that currently limit its utility for evolutionary research:
1. Visualization of comparative genomics data
2. Visualization of phylogenetic data and trees
3. Support for population diversity and phenotype data
If you are interested in these areas and have relevant expertise, you
are strongly encouraged to apply. Relevant areas of expertise include
more than just software development: if you are a GMOD power user,
visualization guru, domain expert (comparative, phylogenetics,
population, ...), or documentation wizard, then your skills are needed!
How To Apply:
Fill out the online application form at http://bit.ly/gmodevohack.
Applications are due August 25.
About GMOD:
GMOD is an intercompatible suite of open-source software components for
storing, managing, analyzing, and visualizing genome-scale data. GMOD
includes many widely-used software components: GBrowse and JBrowse, both
genome viewers; GBrowse_syn, a comparative genomics viewer; Chado, a
generic and modular database schema; CMap, a comparative map viewer; as
well as many other components including Apollo, MAKER, BioMart,
InterMine, and Galaxy. We hope to extend the functionality of existing
GMOD components, and integrate new components as well.
About Hackathons:
A hackathon is an intense event at which a group of programmers with
different backgrounds and skills collaborate hands-on and face-to-face
to develop working code that is of utility to the community as a whole.
The mix of people will include domain experts and computer-savvy end-users.
More details about the event, its motivation, organization, procedures,
and attendees, as well as URLs to the hackathon and related websites are
included below.
Sincerely,
The GMOD EvoHack Organizing Committee (and project affiliations as
relevant):
Nicole Washington, Chair (LBNL, modENCODE, Phenote)
Robert Buels (SGN, Chado NatDiv)
Scott Cain (OICR, GMOD)
Dave Clements (NESCent, GMOD)
Hilmar Lapp (NESCent, Phenoscape, Chado NatDiv)
Sheldon McKay (University of Arizona, iPlant, GBrowse_syn)
-----------------------------
About the GMOD Evo Hackathon
Overview
We are organizing a hackathon to fill critical gaps in the capabilities
of the Generic Model Organism Database (GMOD) toolbox that currently
limit its utility for evolutionary research. Specifically, we will focus
on tools for
1) viewing comparative genomics data;
2) visualizing phylogenomic data; and
3) supporting population diversity data and phenotype annotation.
The event will be hosted at NESCent and bring together a group of about
20+ software developers, end-user representatives, and documentation
experts who would otherwise not meet. The participants will include key
developers of GMOD components that currently lack features critical for
emerging evolutionary biology research, developers of informatics tools
in evolutionary research that lack GMOD integration, and
informatics-savvy biologists who can represent end-user requirements.
The event will provide a unique opportunity to infuse the GMOD developer
community with a heightened awareness of unmet needs in evolutionary
biology that GMOD components have the potential to fill, and for tool
developers in evolutionary biology to better understand how best to
extend or integrate with already existing GMOD components.
Before the Event
Discussion of ideas and sometimes even design actually starts well
before the hackathon, on mailing lists, wiki pages, and conference calls
set up among accepted attendees. This advance work lays the foundation
for participants to be productive from the very first day. This also
means that participants should be willing to contribute some time in
advance of the hackathon itself to participate in this preparatory
discussion.
During the Event
Typically, hackathon participants use the morning of the first day of
the event to organize themselves into working groups of between 3 and 6
people, each with a focused implementation objective. Ideas and
objectives are discussed, and attendees coalesce around the projects in
which they have the most experience or interest.
Deliverables / Event Results
The meeting's attendance, working groups, and outcomes will be fully
logged and documented on the GMOD wiki (http://gmod.org). Each working
group during the event will typically have its own wiki page, linked
from the main EvoHack page, where it documents its minutes and design
notes, and provides links to the code and documentation it produces.
Also, since GMOD and NESCent are both committed to open source
principles, all code and documentation produced by participants during
the hackathon must be published under an OSI-approved open source
license. As contributions to existing GMOD tools, all hackathon products
will most likely satisfy this requirement automatically.
NESCent
This event is sponsored by the US National Evolutionary Synthesis Center
(NESCent, http://www.nescent.org) through its Informatics Whitepapers
program (http://www.nescent.org/informatics/whitepapers.php). NESCent
promotes the synthesis of information, concepts and knowledge to address
significant, emerging, or novel questions in evolutionary science and
its applications. NESCent achieves this by supporting research and
education across disciplinary, institutional, geographic, and
demographic boundaries (see http://www.nescent.org/science/proposals.php).
Links
Main GMOD EvoHack page, and full proposal:
http://gmod.org/wiki/GMOD_Evo_Hackathon
NESCent: http://www.nescent.org/
GMOD: http://gmod.org
Similar past NESCent events, see: http://hackathon.nescent.org/
GMOD hackathon application: http://bit.ly/gmodevohack
--
http://gmod.org/wiki/GMOD_News
http://gmod.org/wiki/GMOD_Europe_2010
http://gmod.org/wiki/Help_Desk_Feedback
From jprocter at compbio.dundee.ac.uk Mon Aug 2 04:18:57 2010
From: jprocter at compbio.dundee.ac.uk (Jim Procter)
Date: Mon, 02 Aug 2010 09:18:57 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To:
References: <9FD87196-C80D-4C59-BE54-374A6CD71D68@ebi.ac.uk>
Message-ID: <4C567F71.7050203@compbio.dundee.ac.uk>
Interesting thread this - it's something that hasn't been properly
discussed at previous DAS developer meetings..
On 30/07/2010 20:33, Dave Messina wrote:
> I too agree with Eugene.
>
> No magic numbers.
You're too late here. 0 *is already* a magic number in the normalised
protein sequence world, since it indicates the transcription start site
for a coding sequence (i.e. the initial M). This is the cause for some
ambiguity in the bio* bindings, and confusion on the part of more simple
minded programmers like myself :)
> Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>
> In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
Agreed. But read on...
> As an example, consider a journal reference ? a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>
> On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
It's a difficult call. The uniprot server's behaviour is almost
certainly due to the ambiguity arising from non-positional annotation
which have start/end attributes (where start==end && start==0), and
those which do not (the annotation is then usually derived from some
other table, viz. the BioSQL schema). Other DAS servers do similar
things, and kludges are needed to fix them.
My only worry with the expectation of 'proper behaviour' - is that
currently, I frequently see IDs with more non-positional annotation than
positional (notwithstanding histogram like continuous quantitative
annotation such as running averages of predicted or observed local
sequence properties). Enforcing compliance with the spec as written
means that the average DAS metaserver (i.e. uniprot, or some server that
aggregates sequence database info with other data) will send a huge
non-positional header in response to every range qualified feature
request, which is pretty inefficient. It may not scale well, either,
since the amount of database cross references is (still) increasing.
> * It might be nice, though, to add 'positional' and 'non-positional' types, which would be a way to grab all of the existing positional or non-positional types in one go. (currently it's necessary to specify multiple types to get the same functionality.)
This is essential, I think. However, the only way you are going to be
able to do this in a DAS type constraint currently is to ensure the
feature annotation source is ontology aware (and said ontology includes
a distinct positional/non-positional hierarchy)**. One route would be to
introduce a DAS-specific type term that the server maps to its source's
ontology, another simpler approach would be to introduce a new boolean
constraint 'positional', which if specified, limits the response to
positional annotation only.
Jim.
** but this immediatly brings to mind a nasty potential gotcha: e.g.
'expression' in the context of a genome is positional, but is a
non-positional feature in the context of a proteome. So terms will have
to be fully qualified in the type constraint on a feature request.
--
-------------------------------------------------------------------
J. B. Procter (JALVIEW/ENFIN) Barton Bioinformatics Research Group
Phone/Fax:+44(0)1382 388734/345764 http://www.compbio.dundee.ac.uk
The University of Dundee is a Scottish Registered Charity, No. SC015096.
From ljgarcia at ebi.ac.uk Mon Aug 2 04:50:51 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Mon, 02 Aug 2010 09:50:51 +0100
Subject: [DAS] querying for nonpositional annotations
Message-ID: <4C5686EB.1040800@ebi.ac.uk>
*Hi list,
*>No magic numbers.
*According to discussions on this matter, I will change MyDas behaviour so 0 will be no
"magic number" any more,
*>Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
>As an example, consider a journal reference --- a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
*and non-positional features will be always returned.
Since UniProt is built upon MyDas, its behaviour will change as well.
Thanks,
Leyla
*
>
>Dave
From andy.jenkinson at ebi.ac.uk Mon Aug 2 05:36:07 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 2 Aug 2010 10:36:07 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <4C5686EB.1040800@ebi.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
Message-ID: <4965F4EF-E3F3-4F47-A37F-5C1D6A68E37A@ebi.ac.uk>
I guess if being unable to filter out nonpositional features proves to be a problem, we can introduce a specific boolean or type-based filter in the next version of the specification.
On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
> *Hi list,
>
> *>No magic numbers.
>
> *According to discussions on this matter, I will change MyDas behaviour so 0 will be no
> "magic number" any more,
>
> *>Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>> In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
>> As an example, consider a journal reference --- a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>> On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
>
> *and non-positional features will be always returned.
> Since UniProt is built upon MyDas, its behaviour will change as well.
>
> Thanks,
>
> Leyla
> *
>
>>
>> Dave
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From jw12 at sanger.ac.uk Mon Aug 2 05:45:50 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 2 Aug 2010 10:45:50 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <4C5686EB.1040800@ebi.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
Message-ID: <4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
I'm not sure I agree with returning all annotations for every tiny
part of a sequence requested.
If you consider DAS to be used for visual display mainly - then it
seems a bit ridiculous to return all publications related to a segment
(take a case where you have many publications related to a protein
sequence). If publications aren't asked for i.e. non-positional
annotations then I don't think they should be given. So I guess I'm
agreeing with Jim here.
Given the history of DAS I would propose a non-positional parameter as
apposed to "positional".
I think we have to remember that the 1.6 spec is supposed to mainly be
a consolidation of the way DAS is being used and DAS is supposed to be
simple (or not overly technical and difficult to pick up anyway).
However- obviously we don't want to propagate practices that really
don't make sense. The 0,0 thing is a hack like we had hacks for
ontologies which now for 1.6 we have cvIds (I think are a big
improvement). So we need something that is simple and obvious for a
big all encompassing thing like positional vs non-positional.
On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
> *Hi list,
>
> *>No magic numbers.
>
> *According to discussions on this matter, I will change MyDas
> behaviour so 0 will be no
> "magic number" any more,
>
> *>Types can be used for filtering, and actually you get more fine-
> grained control than simply positional or non-positional. (I use
> this technique now in DASher.) *
>> In my opinion, the current spec as written is correct. That is, non-
>> positional features don't just apply to the whole sequence, they
>> apply to any part of the sequence.
>> As an example, consider a journal reference --- a particular
>> protein was isolated by a lab, they wrote a paper about it, and
>> deposited the protein sequence in a database. If you look at a
>> subsequence of the protein sequence, that subsequence still derives
>> from the paper, right? So therefore the feature containing that
>> journal reference should still be attached to the subsequence.
>> On that basis, I think the uniprot server is technically doing it
>> wrong and should be changed, although I have to say that in
>> practice it hasn't been an issue for me.
>
> *and non-positional features will be always returned.
> Since UniProt is built upon MyDas, its behaviour will change as well.
>
> Thanks,
>
> Leyla
> *
>
>>
>> Dave
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 ljgarcia at ebi.ac.uk Mon Aug 2 06:29:53 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Mon, 02 Aug 2010 11:29:53 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
Message-ID: <4C569E21.1060302@ebi.ac.uk>
On 02/08/2010 10:45, Jonathan Warren wrote:
> I'm not sure I agree with returning all annotations for every tiny
> part of a sequence requested.
> If you consider DAS to be used for visual display mainly - then it
> seems a bit ridiculous to return all publications related to a segment
> (take a case where you have many publications related to a protein
> sequence). If publications aren't asked for i.e. non-positional
> annotations then I don't think they should be given. So I guess I'm
> agreeing with Jim here.
I think a specific boolean (positional or non-positional) is a better
idea than a type-based filter
> Given the history of DAS I would propose a non-positional parameter as
> apposed to "positional".
>
> I think we have to remember that the 1.6 spec is supposed to mainly be
> a consolidation of the way DAS is being used and DAS is supposed to be
> simple (or not overly technical and difficult to pick up anyway).
> However- obviously we don't want to propagate practices that really
> don't make sense. The 0,0 thing is a hack like we had hacks for
> ontologies which now for 1.6 we have cvIds (I think are a big
> improvement). So we need something that is simple and obvious for a
> big all encompassing thing like positional vs non-positional.
>
>
>
>
> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>
>> *Hi list,
>>
>> *>No magic numbers.
>>
>> *According to discussions on this matter, I will change MyDas
>> behaviour so 0 will be no
>> "magic number" any more,
>>
>> *>Types can be used for filtering, and actually you get more
>> fine-grained control than simply positional or non-positional. (I use
>> this technique now in DASher.) *
>>> In my opinion, the current spec as written is correct. That is,
>>> non-positional features don't just apply to the whole sequence, they
>>> apply to any part of the sequence.
>>> As an example, consider a journal reference --- a particular protein
>>> was isolated by a lab, they wrote a paper about it, and deposited
>>> the protein sequence in a database. If you look at a subsequence of
>>> the protein sequence, that subsequence still derives from the paper,
>>> right? So therefore the feature containing that journal reference
>>> should still be attached to the subsequence.
>>> On that basis, I think the uniprot server is technically doing it
>>> wrong and should be changed, although I have to say that in practice
>>> it hasn't been an issue for me.
>>
>> *and non-positional features will be always returned.
>> Since UniProt is built upon MyDas, its behaviour will change as well.
>>
>> Thanks,
>>
>> Leyla
>> *
>>
>>>
>>> Dave
>>
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
>
>
From andy.jenkinson at ebi.ac.uk Mon Aug 2 08:33:15 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 2 Aug 2010 13:33:15 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
Message-ID: <3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
> I'm not sure I agree with returning all annotations for every tiny part of a sequence requested.
> If you consider DAS to be used for visual display mainly - then it seems a bit ridiculous to return all publications related to a segment (take a case where you have many publications related to a protein sequence). If publications aren't asked for i.e. non-positional annotations then I don't think they should be given. So I guess I'm agreeing with Jim here.
>
> Given the history of DAS I would propose a non-positional parameter as apposed to "positional".
>
> I think we have to remember that the 1.6 spec is supposed to mainly be a consolidation of the way DAS is being used and DAS is supposed to be simple (or not overly technical and difficult to pick up anyway). However- obviously we don't want to propagate practices that really don't make sense. The 0,0 thing is a hack like we had hacks for ontologies which now for 1.6 we have cvIds (I think are a big improvement). So we need something that is simple and obvious for a big all encompassing thing like positional vs non-positional.
I'm not quite sure what you're suggesting we do in 1.6?
>
>
>
> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>
>> *Hi list,
>>
>> *>No magic numbers.
>>
>> *According to discussions on this matter, I will change MyDas behaviour so 0 will be no
>> "magic number" any more,
>>
>> *>Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>>> In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
>>> As an example, consider a journal reference --- a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>>> On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
>>
>> *and non-positional features will be always returned.
>> Since UniProt is built upon MyDas, its behaviour will change as well.
>>
>> Thanks,
>>
>> Leyla
>> *
>>
>>>
>>> Dave
>>
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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 jw12 at sanger.ac.uk Mon Aug 2 11:17:30 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 2 Aug 2010 16:17:30 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
<3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
Message-ID: <97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
Currently having read all points and thought about it properly I
agree with Eugenes summary of what the behavior should be.
I was thinking that types filtering is not implemented and understood
well by many casual users of DAS. But as the types command and
filtering is something we want to encourage using the non-positional
type should encourage this and as long as it's documented well and
splattered everywhere I think it should be fine. But using the logic
below as far as I can see this means you have to do 2 requests if you
want features and non-positional annotations for a range /das/source/
features?segment=P99999:1,150 and /das/source/features?
segment=P99999;type=annotation
But presumably doing /das/source/features?
segment=P99999:1,150;type=gene;type=annotation would actually return
genes if in region but no non-positional results which isn't really
logical on its own?
On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
> On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
>
>> I'm not sure I agree with returning all annotations for every tiny
>> part of a sequence requested.
>> If you consider DAS to be used for visual display mainly - then it
>> seems a bit ridiculous to return all publications related to a
>> segment (take a case where you have many publications related to a
>> protein sequence). If publications aren't asked for i.e. non-
>> positional annotations then I don't think they should be given. So
>> I guess I'm agreeing with Jim here.
>>
>> Given the history of DAS I would propose a non-positional parameter
>> as apposed to "positional".
>>
>> I think we have to remember that the 1.6 spec is supposed to mainly
>> be a consolidation of the way DAS is being used and DAS is supposed
>> to be simple (or not overly technical and difficult to pick up
>> anyway). However- obviously we don't want to propagate practices
>> that really don't make sense. The 0,0 thing is a hack like we had
>> hacks for ontologies which now for 1.6 we have cvIds (I think are a
>> big improvement). So we need something that is simple and obvious
>> for a big all encompassing thing like positional vs non-positional.
>
> I'm not quite sure what you're suggesting we do in 1.6?
>
>>
>>
>>
>> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>>
>>> *Hi list,
>>>
>>> *>No magic numbers.
>>>
>>> *According to discussions on this matter, I will change MyDas
>>> behaviour so 0 will be no
>>> "magic number" any more,
>>>
>>> *>Types can be used for filtering, and actually you get more fine-
>>> grained control than simply positional or non-positional. (I use
>>> this technique now in DASher.) *
>>>> In my opinion, the current spec as written is correct. That is,
>>>> non-positional features don't just apply to the whole sequence,
>>>> they apply to any part of the sequence.
>>>> As an example, consider a journal reference --- a particular
>>>> protein was isolated by a lab, they wrote a paper about it, and
>>>> deposited the protein sequence in a database. If you look at a
>>>> subsequence of the protein sequence, that subsequence still
>>>> derives from the paper, right? So therefore the feature
>>>> containing that journal reference should still be attached to the
>>>> subsequence.
>>>> On that basis, I think the uniprot server is technically doing it
>>>> wrong and should be changed, although I have to say that in
>>>> practice it hasn't been an issue for me.
>>>
>>> *and non-positional features will be always returned.
>>> Since UniProt is built upon MyDas, its behaviour will change as
>>> well.
>>>
>>> Thanks,
>>>
>>> Leyla
>>> *
>>>
>>>>
>>>> Dave
>>>
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> 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
>
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 ljgarcia at ebi.ac.uk Mon Aug 2 12:15:42 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Mon, 02 Aug 2010 17:15:42 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk> <4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk> <3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
<97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
Message-ID: <4C56EF2E.7080800@ebi.ac.uk>
On 02/08/2010 16:17, Jonathan Warren wrote:
> Currently having read all points and thought about it properly I
> agree with Eugenes summary of what the behavior should be.
> I was thinking that types filtering is not implemented and understood
> well by many casual users of DAS. But as the types command and
> filtering is something we want to encourage using the non-positional
> type should encourage this and as long as it's documented well and
> splattered everywhere I think it should be fine. But using the logic
> below as far as I can see this means you have to do 2 requests if you
> want features and non-positional annotations for a range
> /das/source/features?segment=P99999:1,150 and
> /das/source/features?segment=P99999;type=annotation
I think I am confused about the annotation type filter.
Why do you need type=annotation to retrieve non-positional features when
no range is specified? -->
/das/source/features?segment=P99999;type=annotation
If I am not mistaken, no range will retrieve both positional and
non-positional features.
>
> But presumably doing
> /das/source/features?segment=P99999:1,150;type=gene;type=annotation
> would actually return genes if in region but no non-positional results
> which isn't really logical on its own?
So far, non-positional features will be always retrieve, with or without
range. The idea behind using a type filter (type=annotation) is to
specify whether or not non-positional features should be retrieve (or
any other type). So the last query should actually retrieve the
"annotation" type features, or not?
Leyla
>
>
> On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
>
>> On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
>>
>>> I'm not sure I agree with returning all annotations for every tiny
>>> part of a sequence requested.
>>> If you consider DAS to be used for visual display mainly - then it
>>> seems a bit ridiculous to return all publications related to a
>>> segment (take a case where you have many publications related to a
>>> protein sequence). If publications aren't asked for i.e.
>>> non-positional annotations then I don't think they should be given.
>>> So I guess I'm agreeing with Jim here.
>>>
>>> Given the history of DAS I would propose a non-positional parameter
>>> as apposed to "positional".
>>>
>>> I think we have to remember that the 1.6 spec is supposed to mainly
>>> be a consolidation of the way DAS is being used and DAS is supposed
>>> to be simple (or not overly technical and difficult to pick up
>>> anyway). However- obviously we don't want to propagate practices
>>> that really don't make sense. The 0,0 thing is a hack like we had
>>> hacks for ontologies which now for 1.6 we have cvIds (I think are a
>>> big improvement). So we need something that is simple and obvious
>>> for a big all encompassing thing like positional vs non-positional.
>>
>> I'm not quite sure what you're suggesting we do in 1.6?
>>
>>>
>>>
>>>
>>> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>>>
>>>> *Hi list,
>>>>
>>>> *>No magic numbers.
>>>>
>>>> *According to discussions on this matter, I will change MyDas
>>>> behaviour so 0 will be no
>>>> "magic number" any more,
>>>>
>>>> *>Types can be used for filtering, and actually you get more
>>>> fine-grained control than simply positional or non-positional. (I
>>>> use this technique now in DASher.) *
>>>>> In my opinion, the current spec as written is correct. That is,
>>>>> non-positional features don't just apply to the whole sequence,
>>>>> they apply to any part of the sequence.
>>>>> As an example, consider a journal reference --- a particular
>>>>> protein was isolated by a lab, they wrote a paper about it, and
>>>>> deposited the protein sequence in a database. If you look at a
>>>>> subsequence of the protein sequence, that subsequence still
>>>>> derives from the paper, right? So therefore the feature containing
>>>>> that journal reference should still be attached to the subsequence.
>>>>> On that basis, I think the uniprot server is technically doing it
>>>>> wrong and should be changed, although I have to say that in
>>>>> practice it hasn't been an issue for me.
>>>>
>>>> *and non-positional features will be always returned.
>>>> Since UniProt is built upon MyDas, its behaviour will change as well.
>>>>
>>>> Thanks,
>>>>
>>>> Leyla
>>>> *
>>>>
>>>>>
>>>>> Dave
>>>>
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
>
>
From andy.jenkinson at ebi.ac.uk Mon Aug 2 12:17:46 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 2 Aug 2010 17:17:46 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
<3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
<97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
Message-ID:
So just to clarify, is this what you mean?
/das/source/features?segment=P99999 [returns all positional and all nonpositional]
/das/source/features?segment=P99999:1,150 [returns only positional in the query range]
/das/source/features?segment=P99999;type=somenonpositionaltype [returns any feature of the given type, which might be nonpositional]
This is different to what the spec says, but is close to what UniProt does. It does the above, except it also allows this:
/das/source/features?segment=P99999:0,0 [returns only nonpositional]
I think you're saying we should remove the 0,0 capability from MyDas/uniprot, and change the spec wording to reflect that nonpositional features will not be returned if the client specifies a start/end position. Right? :) Sorry for being dumb, am just a bit confused about what you're saying is illogical, etc.
On 2 Aug 2010, at 16:17, Jonathan Warren wrote:
> Currently having read all points and thought about it properly I agree with Eugenes summary of what the behavior should be.
> I was thinking that types filtering is not implemented and understood well by many casual users of DAS. But as the types command and filtering is something we want to encourage using the non-positional type should encourage this and as long as it's documented well and splattered everywhere I think it should be fine. But using the logic below as far as I can see this means you have to do 2 requests if you want features and non-positional annotations for a range /das/source/features?segment=P99999:1,150 and /das/source/features?segment=P99999;type=annotation
>
> But presumably doing /das/source/features?segment=P99999:1,150;type=gene;type=annotation would actually return genes if in region but no non-positional results which isn't really logical on its own?
>
>
> On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
>
>> On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
>>
>>> I'm not sure I agree with returning all annotations for every tiny part of a sequence requested.
>>> If you consider DAS to be used for visual display mainly - then it seems a bit ridiculous to return all publications related to a segment (take a case where you have many publications related to a protein sequence). If publications aren't asked for i.e. non-positional annotations then I don't think they should be given. So I guess I'm agreeing with Jim here.
>>>
>>> Given the history of DAS I would propose a non-positional parameter as apposed to "positional".
>>>
>>> I think we have to remember that the 1.6 spec is supposed to mainly be a consolidation of the way DAS is being used and DAS is supposed to be simple (or not overly technical and difficult to pick up anyway). However- obviously we don't want to propagate practices that really don't make sense. The 0,0 thing is a hack like we had hacks for ontologies which now for 1.6 we have cvIds (I think are a big improvement). So we need something that is simple and obvious for a big all encompassing thing like positional vs non-positional.
>>
>> I'm not quite sure what you're suggesting we do in 1.6?
>>
>>>
>>>
>>>
>>> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>>>
>>>> *Hi list,
>>>>
>>>> *>No magic numbers.
>>>>
>>>> *According to discussions on this matter, I will change MyDas behaviour so 0 will be no
>>>> "magic number" any more,
>>>>
>>>> *>Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>>>>> In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
>>>>> As an example, consider a journal reference --- a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>>>>> On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
>>>>
>>>> *and non-positional features will be always returned.
>>>> Since UniProt is built upon MyDas, its behaviour will change as well.
>>>>
>>>> Thanks,
>>>>
>>>> Leyla
>>>> *
>>>>
>>>>>
>>>>> Dave
>>>>
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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.
From jw12 at sanger.ac.uk Mon Aug 2 12:47:37 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Mon, 2 Aug 2010 17:47:37 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To:
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
<3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
<97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
Message-ID: <0392DE2F-2809-4C5C-AD1C-F83D13678626@sanger.ac.uk>
yes thats what my current thinking was and what I interpreted Eugenes
email as suggesting.
But what I would like to work is this : /das/source/features?
segment=P99999:1,150;type=gene;type=annotation but this won't work if
you have already specified a range - or at least it's not that clear
as to whether it should work.
I guess i'd like it to be a "I want non-positional annotations" rather
than "give me everything and I'll filter out non-positional
annotations by choosing all the other types except positional
annotations".
But this is only my current opinion - we are debating this right?
On 2 Aug 2010, at 17:17, Andy Jenkinson wrote:
> So just to clarify, is this what you mean?
>
> /das/source/features?segment=P99999 [returns all positional and
> all nonpositional]
> /das/source/features?segment=P99999:1,150 [returns only
> positional in the query range]
> /das/source/features?segment=P99999;type=somenonpositionaltype
> [returns any feature of the given type, which might be nonpositional]
>
> This is different to what the spec says, but is close to what
> UniProt does. It does the above, except it also allows this:
>
> /das/source/features?segment=P99999:0,0 [returns only
> nonpositional]
>
> I think you're saying we should remove the 0,0 capability from MyDas/
> uniprot, and change the spec wording to reflect that nonpositional
> features will not be returned if the client specifies a start/end
> position. Right? :) Sorry for being dumb, am just a bit confused
> about what you're saying is illogical, etc.
>
> On 2 Aug 2010, at 16:17, Jonathan Warren wrote:
>
>> Currently having read all points and thought about it properly I
>> agree with Eugenes summary of what the behavior should be.
>> I was thinking that types filtering is not implemented and
>> understood well by many casual users of DAS. But as the types
>> command and filtering is something we want to encourage using the
>> non-positional type should encourage this and as long as it's
>> documented well and splattered everywhere I think it should be
>> fine. But using the logic below as far as I can see this means you
>> have to do 2 requests if you want features and non-positional
>> annotations for a range /das/source/features?segment=P99999:1,150
>> and /das/source/features?segment=P99999;type=annotation
>>
>> But presumably doing /das/source/features?
>> segment=P99999:1,150;type=gene;type=annotation would actually
>> return genes if in region but no non-positional results which isn't
>> really logical on its own?
>>
>>
>> On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
>>
>>> On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
>>>
>>>> I'm not sure I agree with returning all annotations for every
>>>> tiny part of a sequence requested.
>>>> If you consider DAS to be used for visual display mainly - then
>>>> it seems a bit ridiculous to return all publications related to a
>>>> segment (take a case where you have many publications related to
>>>> a protein sequence). If publications aren't asked for i.e. non-
>>>> positional annotations then I don't think they should be given.
>>>> So I guess I'm agreeing with Jim here.
>>>>
>>>> Given the history of DAS I would propose a non-positional
>>>> parameter as apposed to "positional".
>>>>
>>>> I think we have to remember that the 1.6 spec is supposed to
>>>> mainly be a consolidation of the way DAS is being used and DAS is
>>>> supposed to be simple (or not overly technical and difficult to
>>>> pick up anyway). However- obviously we don't want to propagate
>>>> practices that really don't make sense. The 0,0 thing is a hack
>>>> like we had hacks for ontologies which now for 1.6 we have cvIds
>>>> (I think are a big improvement). So we need something that is
>>>> simple and obvious for a big all encompassing thing like
>>>> positional vs non-positional.
>>>
>>> I'm not quite sure what you're suggesting we do in 1.6?
>>>
>>>>
>>>>
>>>>
>>>> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>>>>
>>>>> *Hi list,
>>>>>
>>>>> *>No magic numbers.
>>>>>
>>>>> *According to discussions on this matter, I will change MyDas
>>>>> behaviour so 0 will be no
>>>>> "magic number" any more,
>>>>>
>>>>> *>Types can be used for filtering, and actually you get more
>>>>> fine-grained control than simply positional or non-positional.
>>>>> (I use this technique now in DASher.) *
>>>>>> In my opinion, the current spec as written is correct. That is,
>>>>>> non-positional features don't just apply to the whole sequence,
>>>>>> they apply to any part of the sequence.
>>>>>> As an example, consider a journal reference --- a particular
>>>>>> protein was isolated by a lab, they wrote a paper about it, and
>>>>>> deposited the protein sequence in a database. If you look at a
>>>>>> subsequence of the protein sequence, that subsequence still
>>>>>> derives from the paper, right? So therefore the feature
>>>>>> containing that journal reference should still be attached to
>>>>>> the subsequence.
>>>>>> On that basis, I think the uniprot server is technically doing
>>>>>> it wrong and should be changed, although I have to say that in
>>>>>> practice it hasn't been an issue for me.
>>>>>
>>>>> *and non-positional features will be always returned.
>>>>> Since UniProt is built upon MyDas, its behaviour will change as
>>>>> well.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Leyla
>>>>> *
>>>>>
>>>>>>
>>>>>> Dave
>>>>>
>>>>> _______________________________________________
>>>>> DAS mailing list
>>>>> DAS at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>> Jonathan Warren
>>>> Senior Developer and DAS coordinator
>>>> blog: http://biodasman.wordpress.com/
>>>> 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
>>>
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> 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.
>
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 Aug 2 12:52:28 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Mon, 2 Aug 2010 17:52:28 +0100
Subject: [DAS] querying for nonpositional annotations
In-Reply-To: <0392DE2F-2809-4C5C-AD1C-F83D13678626@sanger.ac.uk>
References: <4C5686EB.1040800@ebi.ac.uk>
<4291A93C-6F52-4C84-A724-25AF59A70A1C@sanger.ac.uk>
<3A234F8D-DB4C-4183-9994-6694E56C8F6A@ebi.ac.uk>
<97C6B89F-F001-4AB6-88E0-1B742FE39DF7@sanger.ac.uk>
<0392DE2F-2809-4C5C-AD1C-F83D13678626@sanger.ac.uk>
Message-ID:
What exactly are the 'annotation' and 'gene' feature types?
On 2 Aug 2010, at 17:47, Jonathan Warren wrote:
> yes thats what my current thinking was and what I interpreted Eugenes email as suggesting.
>
> But what I would like to work is this : /das/source/features?segment=P99999:1,150;type=gene;type=annotation but this won't work if you have already specified a range - or at least it's not that clear as to whether it should work.
>
> I guess i'd like it to be a "I want non-positional annotations" rather than "give me everything and I'll filter out non-positional annotations by choosing all the other types except positional annotations".
>
> But this is only my current opinion - we are debating this right?
>
>
>
> On 2 Aug 2010, at 17:17, Andy Jenkinson wrote:
>
>> So just to clarify, is this what you mean?
>>
>> /das/source/features?segment=P99999 [returns all positional and all nonpositional]
>> /das/source/features?segment=P99999:1,150 [returns only positional in the query range]
>> /das/source/features?segment=P99999;type=somenonpositionaltype [returns any feature of the given type, which might be nonpositional]
>>
>> This is different to what the spec says, but is close to what UniProt does. It does the above, except it also allows this:
>>
>> /das/source/features?segment=P99999:0,0 [returns only nonpositional]
>>
>> I think you're saying we should remove the 0,0 capability from MyDas/uniprot, and change the spec wording to reflect that nonpositional features will not be returned if the client specifies a start/end position. Right? :) Sorry for being dumb, am just a bit confused about what you're saying is illogical, etc.
>>
>> On 2 Aug 2010, at 16:17, Jonathan Warren wrote:
>>
>>> Currently having read all points and thought about it properly I agree with Eugenes summary of what the behavior should be.
>>> I was thinking that types filtering is not implemented and understood well by many casual users of DAS. But as the types command and filtering is something we want to encourage using the non-positional type should encourage this and as long as it's documented well and splattered everywhere I think it should be fine. But using the logic below as far as I can see this means you have to do 2 requests if you want features and non-positional annotations for a range /das/source/features?segment=P99999:1,150 and /das/source/features?segment=P99999;type=annotation
>>>
>>> But presumably doing /das/source/features?segment=P99999:1,150;type=gene;type=annotation would actually return genes if in region but no non-positional results which isn't really logical on its own?
>>>
>>>
>>> On 2 Aug 2010, at 13:33, Andy Jenkinson wrote:
>>>
>>>> On 2 Aug 2010, at 10:45, Jonathan Warren wrote:
>>>>
>>>>> I'm not sure I agree with returning all annotations for every tiny part of a sequence requested.
>>>>> If you consider DAS to be used for visual display mainly - then it seems a bit ridiculous to return all publications related to a segment (take a case where you have many publications related to a protein sequence). If publications aren't asked for i.e. non-positional annotations then I don't think they should be given. So I guess I'm agreeing with Jim here.
>>>>>
>>>>> Given the history of DAS I would propose a non-positional parameter as apposed to "positional".
>>>>>
>>>>> I think we have to remember that the 1.6 spec is supposed to mainly be a consolidation of the way DAS is being used and DAS is supposed to be simple (or not overly technical and difficult to pick up anyway). However- obviously we don't want to propagate practices that really don't make sense. The 0,0 thing is a hack like we had hacks for ontologies which now for 1.6 we have cvIds (I think are a big improvement). So we need something that is simple and obvious for a big all encompassing thing like positional vs non-positional.
>>>>
>>>> I'm not quite sure what you're suggesting we do in 1.6?
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2 Aug 2010, at 09:50, Leyla Garcia wrote:
>>>>>
>>>>>> *Hi list,
>>>>>>
>>>>>> *>No magic numbers.
>>>>>>
>>>>>> *According to discussions on this matter, I will change MyDas behaviour so 0 will be no
>>>>>> "magic number" any more,
>>>>>>
>>>>>> *>Types can be used for filtering, and actually you get more fine-grained control than simply positional or non-positional. (I use this technique now in DASher.) *
>>>>>>> In my opinion, the current spec as written is correct. That is, non-positional features don't just apply to the whole sequence, they apply to any part of the sequence.
>>>>>>> As an example, consider a journal reference --- a particular protein was isolated by a lab, they wrote a paper about it, and deposited the protein sequence in a database. If you look at a subsequence of the protein sequence, that subsequence still derives from the paper, right? So therefore the feature containing that journal reference should still be attached to the subsequence.
>>>>>>> On that basis, I think the uniprot server is technically doing it wrong and should be changed, although I have to say that in practice it hasn't been an issue for me.
>>>>>>
>>>>>> *and non-positional features will be always returned.
>>>>>> Since UniProt is built upon MyDas, its behaviour will change as well.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Leyla
>>>>>> *
>>>>>>
>>>>>>>
>>>>>>> Dave
>>>>>>
>>>>>> _______________________________________________
>>>>>> DAS mailing list
>>>>>> DAS at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>
>>>>> Jonathan Warren
>>>>> Senior Developer and DAS coordinator
>>>>> blog: http://biodasman.wordpress.com/
>>>>> 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
>>>>
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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.
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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.
From thomas.a.down at gmail.com Tue Aug 3 15:41:40 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Tue, 3 Aug 2010 20:41:40 +0100
Subject: [DAS] Dalliance: a new genome DAS client
Message-ID:
As some of you already know, I've been experimenting recently with a
web-based DAS client for genomic data. It's still in
a unashamedly prototypical state (in particular, some of the popups and
configuration stuff is outright clunky, and we know it!), but we're starting
to find it quite useful, and would be interested to receive more feedback.
So if you're curious, you can try it here:
http://www.biodalliance.org/human/ncbi36/
It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
hopefully rather more coming soon), but has one major caveat: since it's
pure Javascript code running in your web browser, there are limitations to
which servers it can connect to. Specifically, it will only work with DAS
servers that implement the W3C cross-origin resource sharing model (which
has been discussed on this list before, but drop me a line if you've got any
questions). What does this mean in practice? If you're adding datasources
from the registry, things are simple because Dalliance will only allow you
to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
some support for this in the registry). If you run your own DAS servers and
don't list them in the registry, you'll need to check for CORS compatibility
yourself. The latest versions of Proserver and Dazzle should both be okay.
All comments, suggestions, and bug reports are welcome!
Thomas Down.
From lincoln.stein at gmail.com Tue Aug 3 15:51:56 2010
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Tue, 3 Aug 2010 15:51:56 -0400
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
Message-ID:
That's really really nice!
Lincoln
On Tue, Aug 3, 2010 at 3:41 PM, Thomas Down wrote:
> As some of you already know, I've been experimenting recently with a
> web-based DAS client for genomic data. It's still in
> a unashamedly prototypical state (in particular, some of the popups and
> configuration stuff is outright clunky, and we know it!), but we're
> starting
> to find it quite useful, and would be interested to receive more feedback.
> So if you're curious, you can try it here:
>
> http://www.biodalliance.org/human/ncbi36/
>
> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
> hopefully rather more coming soon), but has one major caveat: since it's
> pure Javascript code running in your web browser, there are limitations to
> which servers it can connect to. Specifically, it will only work with DAS
> servers that implement the W3C cross-origin resource sharing model (which
> has been discussed on this list before, but drop me a line if you've got
> any
> questions). What does this mean in practice? If you're adding datasources
> from the registry, things are simple because Dalliance will only allow you
> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
> some support for this in the registry). If you run your own DAS servers
> and
> don't list them in the registry, you'll need to check for CORS
> compatibility
> yourself. The latest versions of Proserver and Dazzle should both be okay.
>
> All comments, suggestions, and bug reports are welcome!
>
> Thomas Down.
> _______________________________________________
> 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
From thomas.a.down at gmail.com Tue Aug 3 17:01:24 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Tue, 3 Aug 2010 22:01:24 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID:
On Tue, Aug 3, 2010 at 9:52 PM, Jonathan Warren wrote:
> This is very cool - I had a look the other day. Was wondering why some
> sources could be attached and some can't....
That's a good point, I should add an explanation of why some sources aren't
available actually inside the registry browser. Do you think I can get away
with an "e-mail the server administrator on xxx at yyy.com and demand CORS
today" message? :-).
Thomas.
From jw12 at sanger.ac.uk Tue Aug 3 16:52:07 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Tue, 3 Aug 2010 21:52:07 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
Message-ID: <3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
This is very cool - I had a look the other day. Was wondering why some
sources could be attached and some can't....
Best browser experience yet by far I'd say.
No problems about adding CORS support - for the record I'm very happy
to implement new capabilities testing and other suggestions to the
registry from anyone who cares to drop me a line. Especially if it's
going to enhance and promote the use of the registry :)
On 3 Aug 2010, at 20:41, Thomas Down wrote:
> As some of you already know, I've been experimenting recently with a
> web-based DAS client for genomic data. It's still in
> a unashamedly prototypical state (in particular, some of the popups
> and
> configuration stuff is outright clunky, and we know it!), but we're
> starting
> to find it quite useful, and would be interested to receive more
> feedback.
> So if you're curious, you can try it here:
>
> http://www.biodalliance.org/human/ncbi36/
>
> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
> hopefully rather more coming soon), but has one major caveat: since
> it's
> pure Javascript code running in your web browser, there are
> limitations to
> which servers it can connect to. Specifically, it will only work
> with DAS
> servers that implement the W3C cross-origin resource sharing model
> (which
> has been discussed on this list before, but drop me a line if you've
> got any
> questions). What does this mean in practice? If you're adding
> datasources
> from the registry, things are simple because Dalliance will only
> allow you
> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
> adding
> some support for this in the registry). If you run your own DAS
> servers and
> don't list them in the registry, you'll need to check for CORS
> compatibility
> yourself. The latest versions of Proserver and Dazzle should both
> be okay.
>
> All comments, suggestions, and bug reports are welcome!
>
> Thomas Down.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 lincoln.stein at gmail.com Tue Aug 3 17:21:12 2010
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Tue, 3 Aug 2010 17:21:12 -0400
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID:
Someone give me a quick summary of CORS support. I want to make sure that
GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
something new?)
Lincoln
On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren wrote:
> This is very cool - I had a look the other day. Was wondering why some
> sources could be attached and some can't....
> Best browser experience yet by far I'd say.
>
> No problems about adding CORS support - for the record I'm very happy to
> implement new capabilities testing and other suggestions to the registry
> from anyone who cares to drop me a line. Especially if it's going to enhance
> and promote the use of the registry :)
>
>
>
> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>
> As some of you already know, I've been experimenting recently with a
>> web-based DAS client for genomic data. It's still in
>> a unashamedly prototypical state (in particular, some of the popups and
>> configuration stuff is outright clunky, and we know it!), but we're
>> starting
>> to find it quite useful, and would be interested to receive more feedback.
>> So if you're curious, you can try it here:
>>
>> http://www.biodalliance.org/human/ncbi36/
>>
>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>> hopefully rather more coming soon), but has one major caveat: since it's
>> pure Javascript code running in your web browser, there are limitations to
>> which servers it can connect to. Specifically, it will only work with DAS
>> servers that implement the W3C cross-origin resource sharing model (which
>> has been discussed on this list before, but drop me a line if you've got
>> any
>> questions). What does this mean in practice? If you're adding
>> datasources
>> from the registry, things are simple because Dalliance will only allow you
>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>> some support for this in the registry). If you run your own DAS servers
>> and
>> don't list them in the registry, you'll need to check for CORS
>> compatibility
>> yourself. The latest versions of Proserver and Dazzle should both be
>> okay.
>>
>> All comments, suggestions, and bug reports are welcome!
>>
>> Thomas Down.
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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
>
--
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
From thomas.a.down at gmail.com Tue Aug 3 17:28:40 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Tue, 3 Aug 2010 22:28:40 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID:
Jonathan's written a nice summary here:
http://biodasman.wordpress.com/2010/07/20/cors/
But briefly... it's the "official" way to work around the same-origin
policy (by default, browsers only allow unsigned javascript to trigger HTTP
requests to the server from which it was originally downloaded). The
specification is here:
http://www.w3.org/TR/cors/
(Please don't be too alarmed by the datestamp! The core parts have been
stable for > a year now, and it's well supported by Mozilla, WebKit, and --
via a slightly different API -- Internet Explorer).
If you're running a public server and want it to be CORS accessible, all
that is needed is to emit the header:
Access-Control-Allow-Origin: *
...and you're done.
(If you're running password-protected DAS servers, or DAS servers hosting
sensitive information behind a firewall, you might want a slightly more
sophisticated CORS implementation. Happy to discuss if anyone is
interested).
Thomas.
On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein wrote:
> Someone give me a quick summary of CORS support. I want to make sure that
> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
> something new?)
>
> Lincoln
>
> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren wrote:
>
>> This is very cool - I had a look the other day. Was wondering why some
>> sources could be attached and some can't....
>> Best browser experience yet by far I'd say.
>>
>> No problems about adding CORS support - for the record I'm very happy to
>> implement new capabilities testing and other suggestions to the registry
>> from anyone who cares to drop me a line. Especially if it's going to enhance
>> and promote the use of the registry :)
>>
>>
>>
>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>
>> As some of you already know, I've been experimenting recently with a
>>> web-based DAS client for genomic data. It's still in
>>> a unashamedly prototypical state (in particular, some of the popups and
>>> configuration stuff is outright clunky, and we know it!), but we're
>>> starting
>>> to find it quite useful, and would be interested to receive more
>>> feedback.
>>> So if you're curious, you can try it here:
>>>
>>> http://www.biodalliance.org/human/ncbi36/
>>>
>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>> hopefully rather more coming soon), but has one major caveat: since it's
>>> pure Javascript code running in your web browser, there are limitations
>>> to
>>> which servers it can connect to. Specifically, it will only work with
>>> DAS
>>> servers that implement the W3C cross-origin resource sharing model (which
>>> has been discussed on this list before, but drop me a line if you've got
>>> any
>>> questions). What does this mean in practice? If you're adding
>>> datasources
>>> from the registry, things are simple because Dalliance will only allow
>>> you
>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>>> some support for this in the registry). If you run your own DAS servers
>>> and
>>> don't list them in the registry, you'll need to check for CORS
>>> compatibility
>>> yourself. The latest versions of Proserver and Dazzle should both be
>>> okay.
>>>
>>> All comments, suggestions, and bug reports are welcome!
>>>
>>> Thomas Down.
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> 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
>>
>
>
>
> --
> 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
>
From ljgarcia at ebi.ac.uk Wed Aug 4 10:03:41 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Wed, 04 Aug 2010 15:03:41 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID: <4C59733D.4090304@ebi.ac.uk>
About CORS,
>If you run your own DAS servers and
>don't list them in the registry, you'll need to check for CORS
compatibility
>yourself. The latest versions of Proserver and Dazzle should both be
okay.
If I am not mistaken, Proserver already implements CORS headers?
Andy, could you please send me a link of a Proserver server that
implements this?
Thanks,
Leyla
On 03/08/2010 21:52, Jonathan Warren wrote:
> This is very cool - I had a look the other day. Was wondering why some
> sources could be attached and some can't....
> Best browser experience yet by far I'd say.
>
> No problems about adding CORS support - for the record I'm very happy
> to implement new capabilities testing and other suggestions to the
> registry from anyone who cares to drop me a line. Especially if it's
> going to enhance and promote the use of the registry :)
>
>
> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>
>> As some of you already know, I've been experimenting recently with a
>> web-based DAS client for genomic data. It's still in
>> a unashamedly prototypical state (in particular, some of the popups and
>> configuration stuff is outright clunky, and we know it!), but we're
>> starting
>> to find it quite useful, and would be interested to receive more
>> feedback.
>> So if you're curious, you can try it here:
>>
>> http://www.biodalliance.org/human/ncbi36/
>>
>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>> hopefully rather more coming soon), but has one major caveat: since it's
>> pure Javascript code running in your web browser, there are
>> limitations to
>> which servers it can connect to. Specifically, it will only work
>> with DAS
>> servers that implement the W3C cross-origin resource sharing model
>> (which
>> has been discussed on this list before, but drop me a line if you've
>> got any
>> questions). What does this mean in practice? If you're adding
>> datasources
>> from the registry, things are simple because Dalliance will only
>> allow you
>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>> some support for this in the registry). If you run your own DAS
>> servers and
>> don't list them in the registry, you'll need to check for CORS
>> compatibility
>> yourself. The latest versions of Proserver and Dazzle should both be
>> okay.
>>
>> All comments, suggestions, and bug reports are welcome!
>>
>> Thomas Down.
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
>
>
From jw12 at sanger.ac.uk Wed Aug 4 10:51:06 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 4 Aug 2010 15:51:06 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <4C59733D.4090304@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
Message-ID:
This url list 150 das sources that implement cors - see traffic light
on the end:
http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
You can check the headers responses for any of their valid responses.
If you want some java code that adds this functionality to MyDAS I
can send it to you...
On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
> About CORS,
>
> >If you run your own DAS servers and
> >don't list them in the registry, you'll need to check for CORS
> compatibility
> >yourself. The latest versions of Proserver and Dazzle should both
> be okay.
>
> If I am not mistaken, Proserver already implements CORS headers?
> Andy, could you please send me a link of a Proserver server that
> implements this?
>
> Thanks,
>
> Leyla
>
> On 03/08/2010 21:52, Jonathan Warren wrote:
>> This is very cool - I had a look the other day. Was wondering why
>> some sources could be attached and some can't....
>> Best browser experience yet by far I'd say.
>>
>> No problems about adding CORS support - for the record I'm very
>> happy to implement new capabilities testing and other suggestions
>> to the registry from anyone who cares to drop me a line. Especially
>> if it's going to enhance and promote the use of the registry :)
>>
>>
>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>
>>> As some of you already know, I've been experimenting recently with a
>>> web-based DAS client for genomic data. It's still in
>>> a unashamedly prototypical state (in particular, some of the
>>> popups and
>>> configuration stuff is outright clunky, and we know it!), but
>>> we're starting
>>> to find it quite useful, and would be interested to receive more
>>> feedback.
>>> So if you're curious, you can try it here:
>>>
>>> http://www.biodalliance.org/human/ncbi36/
>>>
>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6,
>>> and
>>> hopefully rather more coming soon), but has one major caveat:
>>> since it's
>>> pure Javascript code running in your web browser, there are
>>> limitations to
>>> which servers it can connect to. Specifically, it will only work
>>> with DAS
>>> servers that implement the W3C cross-origin resource sharing model
>>> (which
>>> has been discussed on this list before, but drop me a line if
>>> you've got any
>>> questions). What does this mean in practice? If you're adding
>>> datasources
>>> from the registry, things are simple because Dalliance will only
>>> allow you
>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>>> adding
>>> some support for this in the registry). If you run your own DAS
>>> servers and
>>> don't list them in the registry, you'll need to check for CORS
>>> compatibility
>>> yourself. The latest versions of Proserver and Dazzle should both
>>> be okay.
>>>
>>> All comments, suggestions, and bug reports are welcome!
>>>
>>> Thomas Down.
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> jw12 at sanger.ac.uk
>> Ext: 2314
>> Telephone: 01223 492314
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 Wed Aug 4 10:53:05 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 4 Aug 2010 15:53:05 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <4C59733D.4090304@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
Message-ID: <6A5CF73C-4C54-4A45-B0C3-3D589C1C732D@ebi.ac.uk>
Sure:
http://www.ebi.ac.uk/das-srv/genomicdas/das/sources
The implementation in ProServer is a bit more advanced in that it deals with preflight (HTTP "options") requests. These are necessary if the client sends custom headers (err, like X-DAS-Client in DAS 1.6) and non-simple requests (such as PUT). Cross-origin writeback would require preflight request support, for example.
By the way, I just looked at the CORS spec and have made some changes to ProServer's implementation to support the 'expose headers' portion of the spec. Either this wasn't there last year or I missed it. I think this is necessary before the browser will get access to the custom DAS headers such as X-DAS-Status.
Here's some code:
if ($request->method eq 'options') {
# For W3C Access Control preflight requests
$response->header('Access-Control-Allow-Methods' => 'GET, POST, OPTIONS');
$response->header('Access-Control-Allow-Headers' => 'X-DAS-Version, X-DAS-Client');
$response->header('Access-Control-Max-Age', => '2592000'); # preflight can be cached for 30 days
}
# Add Access Control headers (for cross site requests):
$response->header('Access-Control-Allow-Origin' => $request->header('Origin') || '*');
$response->header('Access-Control-Expose-Headers' => 'X-DAS-Version, X-DAS-Server, X-DAS-Status, X-DAS-Capabilities');
$response->header('Access-Control-Allow-Credentials' => 'true');
Cheers,
Andy
On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
> About CORS,
>
> >If you run your own DAS servers and
> >don't list them in the registry, you'll need to check for CORS compatibility
> >yourself. The latest versions of Proserver and Dazzle should both be okay.
>
> If I am not mistaken, Proserver already implements CORS headers?
> Andy, could you please send me a link of a Proserver server that implements this?
>
> Thanks,
>
> Leyla
>
> On 03/08/2010 21:52, Jonathan Warren wrote:
>> This is very cool - I had a look the other day. Was wondering why some sources could be attached and some can't....
>> Best browser experience yet by far I'd say.
>>
>> No problems about adding CORS support - for the record I'm very happy to implement new capabilities testing and other suggestions to the registry from anyone who cares to drop me a line. Especially if it's going to enhance and promote the use of the registry :)
>>
>>
>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>
>>> As some of you already know, I've been experimenting recently with a
>>> web-based DAS client for genomic data. It's still in
>>> a unashamedly prototypical state (in particular, some of the popups and
>>> configuration stuff is outright clunky, and we know it!), but we're starting
>>> to find it quite useful, and would be interested to receive more feedback.
>>> So if you're curious, you can try it here:
>>>
>>> http://www.biodalliance.org/human/ncbi36/
>>>
>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>> hopefully rather more coming soon), but has one major caveat: since it's
>>> pure Javascript code running in your web browser, there are limitations to
>>> which servers it can connect to. Specifically, it will only work with DAS
>>> servers that implement the W3C cross-origin resource sharing model (which
>>> has been discussed on this list before, but drop me a line if you've got any
>>> questions). What does this mean in practice? If you're adding datasources
>>> from the registry, things are simple because Dalliance will only allow you
>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>>> some support for this in the registry). If you run your own DAS servers and
>>> don't list them in the registry, you'll need to check for CORS compatibility
>>> yourself. The latest versions of Proserver and Dazzle should both be okay.
>>>
>>> All comments, suggestions, and bug reports are welcome!
>>>
>>> Thomas Down.
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> jw12 at sanger.ac.uk
>> Ext: 2314
>> Telephone: 01223 492314
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From jw12 at sanger.ac.uk Wed Aug 4 10:54:04 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 4 Aug 2010 15:54:04 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
Message-ID:
resp.setHeader("Access-Control-Allow-Origin", "*");
On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
> This url list 150 das sources that implement cors - see traffic
> light on the end:
>
> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>
> You can check the headers responses for any of their valid responses.
>
> If you want some java code that adds this functionality to MyDAS I
> can send it to you...
>
> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>
>> About CORS,
>>
>> >If you run your own DAS servers and
>> >don't list them in the registry, you'll need to check for CORS
>> compatibility
>> >yourself. The latest versions of Proserver and Dazzle should both
>> be okay.
>>
>> If I am not mistaken, Proserver already implements CORS headers?
>> Andy, could you please send me a link of a Proserver server that
>> implements this?
>>
>> Thanks,
>>
>> Leyla
>>
>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>> This is very cool - I had a look the other day. Was wondering why
>>> some sources could be attached and some can't....
>>> Best browser experience yet by far I'd say.
>>>
>>> No problems about adding CORS support - for the record I'm very
>>> happy to implement new capabilities testing and other suggestions
>>> to the registry from anyone who cares to drop me a line.
>>> Especially if it's going to enhance and promote the use of the
>>> registry :)
>>>
>>>
>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>
>>>> As some of you already know, I've been experimenting recently
>>>> with a
>>>> web-based DAS client for genomic data. It's still in
>>>> a unashamedly prototypical state (in particular, some of the
>>>> popups and
>>>> configuration stuff is outright clunky, and we know it!), but
>>>> we're starting
>>>> to find it quite useful, and would be interested to receive more
>>>> feedback.
>>>> So if you're curious, you can try it here:
>>>>
>>>> http://www.biodalliance.org/human/ncbi36/
>>>>
>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6,
>>>> and
>>>> hopefully rather more coming soon), but has one major caveat:
>>>> since it's
>>>> pure Javascript code running in your web browser, there are
>>>> limitations to
>>>> which servers it can connect to. Specifically, it will only work
>>>> with DAS
>>>> servers that implement the W3C cross-origin resource sharing
>>>> model (which
>>>> has been discussed on this list before, but drop me a line if
>>>> you've got any
>>>> questions). What does this mean in practice? If you're adding
>>>> datasources
>>>> from the registry, things are simple because Dalliance will only
>>>> allow you
>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>>>> adding
>>>> some support for this in the registry). If you run your own DAS
>>>> servers and
>>>> don't list them in the registry, you'll need to check for CORS
>>>> compatibility
>>>> yourself. The latest versions of Proserver and Dazzle should
>>>> both be okay.
>>>>
>>>> All comments, suggestions, and bug reports are welcome!
>>>>
>>>> Thomas Down.
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> jw12 at sanger.ac.uk
>>> Ext: 2314
>>> Telephone: 01223 492314
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> jw12 at sanger.ac.uk
> Ext: 2314
> Telephone: 01223 492314
>
>
>
>
>
>
>
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 Wed Aug 4 10:55:55 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 4 Aug 2010 15:55:55 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID:
If you want the application to be able to access the 1.53 X-DAS headers I think you also need:
Access-Control-Expose-Headers: X-DAS-Version, X-DAS-Server, X-DAS-Status, X-DAS-Capabilities
(see my previous mail to the list).
In DAS 1.6, there are some client headers too, which would require handling of the CORS preflight request (again, see my previous mail).
On 3 Aug 2010, at 22:28, Thomas Down wrote:
> Jonathan's written a nice summary here:
>
> http://biodasman.wordpress.com/2010/07/20/cors/
>
> But briefly... it's the "official" way to work around the same-origin
> policy (by default, browsers only allow unsigned javascript to trigger HTTP
> requests to the server from which it was originally downloaded). The
> specification is here:
>
> http://www.w3.org/TR/cors/
>
> (Please don't be too alarmed by the datestamp! The core parts have been
> stable for > a year now, and it's well supported by Mozilla, WebKit, and --
> via a slightly different API -- Internet Explorer).
>
> If you're running a public server and want it to be CORS accessible, all
> that is needed is to emit the header:
>
> Access-Control-Allow-Origin: *
>
> ...and you're done.
>
> (If you're running password-protected DAS servers, or DAS servers hosting
> sensitive information behind a firewall, you might want a slightly more
> sophisticated CORS implementation. Happy to discuss if anyone is
> interested).
>
> Thomas.
>
> On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein wrote:
>
>> Someone give me a quick summary of CORS support. I want to make sure that
>> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
>> something new?)
>>
>> Lincoln
>>
>> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren wrote:
>>
>>> This is very cool - I had a look the other day. Was wondering why some
>>> sources could be attached and some can't....
>>> Best browser experience yet by far I'd say.
>>>
>>> No problems about adding CORS support - for the record I'm very happy to
>>> implement new capabilities testing and other suggestions to the registry
>>> from anyone who cares to drop me a line. Especially if it's going to enhance
>>> and promote the use of the registry :)
>>>
>>>
>>>
>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>
>>> As some of you already know, I've been experimenting recently with a
>>>> web-based DAS client for genomic data. It's still in
>>>> a unashamedly prototypical state (in particular, some of the popups and
>>>> configuration stuff is outright clunky, and we know it!), but we're
>>>> starting
>>>> to find it quite useful, and would be interested to receive more
>>>> feedback.
>>>> So if you're curious, you can try it here:
>>>>
>>>> http://www.biodalliance.org/human/ncbi36/
>>>>
>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>>> hopefully rather more coming soon), but has one major caveat: since it's
>>>> pure Javascript code running in your web browser, there are limitations
>>>> to
>>>> which servers it can connect to. Specifically, it will only work with
>>>> DAS
>>>> servers that implement the W3C cross-origin resource sharing model (which
>>>> has been discussed on this list before, but drop me a line if you've got
>>>> any
>>>> questions). What does this mean in practice? If you're adding
>>>> datasources
>>>> from the registry, things are simple because Dalliance will only allow
>>>> you
>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>>>> some support for this in the registry). If you run your own DAS servers
>>>> and
>>>> don't list them in the registry, you'll need to check for CORS
>>>> compatibility
>>>> yourself. The latest versions of Proserver and Dazzle should both be
>>>> okay.
>>>>
>>>> All comments, suggestions, and bug reports are welcome!
>>>>
>>>> Thomas Down.
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From andy.jenkinson at ebi.ac.uk Wed Aug 4 10:58:45 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 4 Aug 2010 15:58:45 +0100
Subject: [DAS] CORS
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
Message-ID: <3378D8DA-614B-4D56-93AD-024DAFF7F61D@ebi.ac.uk>
Since this seems to have been given the thumbs up, shall we make CORS support mandatory from 1.6 onwards?
I suggested this when it first came up last year, but I got no replies so didn't put it in the spec. I suspect because it was in the middle of a flurry of emails about "maxbins" :)
On 3 Aug 2010, at 22:28, Thomas Down wrote:
> Jonathan's written a nice summary here:
>
> http://biodasman.wordpress.com/2010/07/20/cors/
>
> But briefly... it's the "official" way to work around the same-origin
> policy (by default, browsers only allow unsigned javascript to trigger HTTP
> requests to the server from which it was originally downloaded). The
> specification is here:
>
> http://www.w3.org/TR/cors/
>
> (Please don't be too alarmed by the datestamp! The core parts have been
> stable for > a year now, and it's well supported by Mozilla, WebKit, and --
> via a slightly different API -- Internet Explorer).
>
> If you're running a public server and want it to be CORS accessible, all
> that is needed is to emit the header:
>
> Access-Control-Allow-Origin: *
>
> ...and you're done.
>
> (If you're running password-protected DAS servers, or DAS servers hosting
> sensitive information behind a firewall, you might want a slightly more
> sophisticated CORS implementation. Happy to discuss if anyone is
> interested).
>
> Thomas.
>
> On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein wrote:
>
>> Someone give me a quick summary of CORS support. I want to make sure that
>> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
>> something new?)
>>
>> Lincoln
>>
>> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren wrote:
>>
>>> This is very cool - I had a look the other day. Was wondering why some
>>> sources could be attached and some can't....
>>> Best browser experience yet by far I'd say.
>>>
>>> No problems about adding CORS support - for the record I'm very happy to
>>> implement new capabilities testing and other suggestions to the registry
>>> from anyone who cares to drop me a line. Especially if it's going to enhance
>>> and promote the use of the registry :)
>>>
>>>
>>>
>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>
>>> As some of you already know, I've been experimenting recently with a
>>>> web-based DAS client for genomic data. It's still in
>>>> a unashamedly prototypical state (in particular, some of the popups and
>>>> configuration stuff is outright clunky, and we know it!), but we're
>>>> starting
>>>> to find it quite useful, and would be interested to receive more
>>>> feedback.
>>>> So if you're curious, you can try it here:
>>>>
>>>> http://www.biodalliance.org/human/ncbi36/
>>>>
>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>>> hopefully rather more coming soon), but has one major caveat: since it's
>>>> pure Javascript code running in your web browser, there are limitations
>>>> to
>>>> which servers it can connect to. Specifically, it will only work with
>>>> DAS
>>>> servers that implement the W3C cross-origin resource sharing model (which
>>>> has been discussed on this list before, but drop me a line if you've got
>>>> any
>>>> questions). What does this mean in practice? If you're adding
>>>> datasources
>>>> from the registry, things are simple because Dalliance will only allow
>>>> you
>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
>>>> some support for this in the registry). If you run your own DAS servers
>>>> and
>>>> don't list them in the registry, you'll need to check for CORS
>>>> compatibility
>>>> yourself. The latest versions of Proserver and Dazzle should both be
>>>> okay.
>>>>
>>>> All comments, suggestions, and bug reports are welcome!
>>>>
>>>> Thomas Down.
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From thomas.a.down at gmail.com Wed Aug 4 10:59:00 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 4 Aug 2010 15:59:00 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <6A5CF73C-4C54-4A45-B0C3-3D589C1C732D@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<6A5CF73C-4C54-4A45-B0C3-3D589C1C732D@ebi.ac.uk>
Message-ID:
On Wed, Aug 4, 2010 at 3:53 PM, Andy Jenkinson wrote:
> Sure:
> http://www.ebi.ac.uk/das-srv/genomicdas/das/sources
>
> The implementation in ProServer is a bit more advanced in that it deals
> with preflight (HTTP "options") requests. These are necessary if the client
> sends custom headers (err, like X-DAS-Client in DAS 1.6) and non-simple
> requests (such as PUT). Cross-origin writeback would require preflight
> request support, for example.
>
> By the way, I just looked at the CORS spec and have made some changes to
> ProServer's implementation to support the 'expose headers' portion of the
> spec. Either this wasn't there last year or I missed it. I think this is
> necessary before the browser will get access to the custom DAS headers such
> as X-DAS-Status.
>
Yes, Access-Control-Expose-Headers is a new addition in the latest draft --
and, as you say, kind-of useful for DAS (specifically: we'll be able to
implement zooming rather more efficiently in Dalliance once we can detect
which sources actually implement maxbins -- which is currently a problem).
Unfortunately, the client support for this bit isn't there yet (see, for
instance, https://bugs.webkit.org/show_bug.cgi?id=41210), but will hopefully
appear soon!
Thomas.
From ljgarcia at ebi.ac.uk Wed Aug 4 11:03:33 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Wed, 04 Aug 2010 16:03:33 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
Message-ID: <4C598145.5090007@ebi.ac.uk>
Thanks Andy and Jonathan,
The CORS header is already in MyDAS and it will be available for the
next release, which will be soon :)
I will check the specification about Access-Control-Expose-Headers
Jonathan, I am checking the response headers with an add-on in Firefox.
I tried the first URL in the dasregistry link you send me, i.e.
http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
but I do not see the Access-Control-Allow-Origin header there. So I am
not sure what I missing...
Leyla
On 04/08/2010 15:54, Jonathan Warren wrote:
> resp.setHeader("Access-Control-Allow-Origin", "*");
>
> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>
>> This url list 150 das sources that implement cors - see traffic light
>> on the end:
>>
>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>
>>
>> You can check the headers responses for any of their valid responses.
>>
>> If you want some java code that adds this functionality to MyDAS I
>> can send it to you...
>>
>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>
>>> About CORS,
>>>
>>> >If you run your own DAS servers and
>>> >don't list them in the registry, you'll need to check for CORS
>>> compatibility
>>> >yourself. The latest versions of Proserver and Dazzle should both
>>> be okay.
>>>
>>> If I am not mistaken, Proserver already implements CORS headers?
>>> Andy, could you please send me a link of a Proserver server that
>>> implements this?
>>>
>>> Thanks,
>>>
>>> Leyla
>>>
>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>> This is very cool - I had a look the other day. Was wondering why
>>>> some sources could be attached and some can't....
>>>> Best browser experience yet by far I'd say.
>>>>
>>>> No problems about adding CORS support - for the record I'm very
>>>> happy to implement new capabilities testing and other suggestions
>>>> to the registry from anyone who cares to drop me a line. Especially
>>>> if it's going to enhance and promote the use of the registry :)
>>>>
>>>>
>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>
>>>>> As some of you already know, I've been experimenting recently with a
>>>>> web-based DAS client for genomic data. It's still in
>>>>> a unashamedly prototypical state (in particular, some of the
>>>>> popups and
>>>>> configuration stuff is outright clunky, and we know it!), but
>>>>> we're starting
>>>>> to find it quite useful, and would be interested to receive more
>>>>> feedback.
>>>>> So if you're curious, you can try it here:
>>>>>
>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>
>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>>>> hopefully rather more coming soon), but has one major caveat:
>>>>> since it's
>>>>> pure Javascript code running in your web browser, there are
>>>>> limitations to
>>>>> which servers it can connect to. Specifically, it will only work
>>>>> with DAS
>>>>> servers that implement the W3C cross-origin resource sharing model
>>>>> (which
>>>>> has been discussed on this list before, but drop me a line if
>>>>> you've got any
>>>>> questions). What does this mean in practice? If you're adding
>>>>> datasources
>>>>> from the registry, things are simple because Dalliance will only
>>>>> allow you
>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>>>>> adding
>>>>> some support for this in the registry). If you run your own DAS
>>>>> servers and
>>>>> don't list them in the registry, you'll need to check for CORS
>>>>> compatibility
>>>>> yourself. The latest versions of Proserver and Dazzle should both
>>>>> be okay.
>>>>>
>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>
>>>>> Thomas Down.
>>>>> _______________________________________________
>>>>> DAS mailing list
>>>>> DAS at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>> Jonathan Warren
>>>> Senior Developer and DAS coordinator
>>>> blog: http://biodasman.wordpress.com/
>>>> jw12 at sanger.ac.uk
>>>> Ext: 2314
>>>> Telephone: 01223 492314
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> jw12 at sanger.ac.uk
>> Ext: 2314
>> Telephone: 01223 492314
>>
>>
>>
>>
>>
>>
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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 Wed Aug 4 11:06:27 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 4 Aug 2010 16:06:27 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<6A5CF73C-4C54-4A45-B0C3-3D589C1C732D@ebi.ac.uk>
Message-ID:
On 4 Aug 2010, at 15:59, Thomas Down wrote:
>
> Yes, Access-Control-Expose-Headers is a new addition in the latest draft -- and, as you say, kind-of useful for DAS (specifically: we'll be able to implement zooming rather more efficiently in Dalliance once we can detect which sources actually implement maxbins -- which is currently a problem).
>
> Unfortunately, the client support for this bit isn't there yet (see, for instance, https://bugs.webkit.org/show_bug.cgi?id=41210), but will hopefully appear soon!
>
> Thomas.
OK, so clients (or safari/chrome at least) strip the headers from the response at the moment. There's always the sources command... if it's listed in X-DAS-Capabilities, it should be listed in the sources command ;)
From jw12 at sanger.ac.uk Wed Aug 4 11:09:43 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Wed, 4 Aug 2010 16:09:43 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <4C598145.5090007@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID:
On 4 Aug 2010, at 16:03, Leyla Garcia wrote:
> Thanks Andy and Jonathan,
>
> The CORS header is already in MyDAS and it will be available for the
> next release, which will be soon :)
> I will check the specification about Access-Control-Expose-Headers
>
Great stuff.
> Jonathan, I am checking the response headers with an add-on in
> Firefox. I tried the first URL in the dasregistry link you send me,
> i.e. http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
> but I do not see the Access-Control-Allow-Origin header there. So I
> am not sure what I missing...
>
Thats odd - the first in the list is "structure" source and is run by
the sanger which has cors in the header ( I just checked using the
firefox plugin)- did you use the whole url I sent?
> Leyla
>
>
> On 04/08/2010 15:54, Jonathan Warren wrote:
>>
>> resp.setHeader("Access-Control-Allow-Origin", "*");
>>
>> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>>
>>> This url list 150 das sources that implement cors - see traffic
>>> light on the end:
>>>
>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>>
>>> You can check the headers responses for any of their valid
>>> responses.
>>>
>>> If you want some java code that adds this functionality to MyDAS
>>> I can send it to you...
>>>
>>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>>
>>>> About CORS,
>>>>
>>>> >If you run your own DAS servers and
>>>> >don't list them in the registry, you'll need to check for CORS
>>>> compatibility
>>>> >yourself. The latest versions of Proserver and Dazzle should
>>>> both be okay.
>>>>
>>>> If I am not mistaken, Proserver already implements CORS headers?
>>>> Andy, could you please send me a link of a Proserver server that
>>>> implements this?
>>>>
>>>> Thanks,
>>>>
>>>> Leyla
>>>>
>>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>>> This is very cool - I had a look the other day. Was wondering
>>>>> why some sources could be attached and some can't....
>>>>> Best browser experience yet by far I'd say.
>>>>>
>>>>> No problems about adding CORS support - for the record I'm very
>>>>> happy to implement new capabilities testing and other
>>>>> suggestions to the registry from anyone who cares to drop me a
>>>>> line. Especially if it's going to enhance and promote the use of
>>>>> the registry :)
>>>>>
>>>>>
>>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>>
>>>>>> As some of you already know, I've been experimenting recently
>>>>>> with a
>>>>>> web-based DAS client for genomic data. It's still in
>>>>>> a unashamedly prototypical state (in particular, some of the
>>>>>> popups and
>>>>>> configuration stuff is outright clunky, and we know it!), but
>>>>>> we're starting
>>>>>> to find it quite useful, and would be interested to receive
>>>>>> more feedback.
>>>>>> So if you're curious, you can try it here:
>>>>>>
>>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>>
>>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/
>>>>>> 1.6, and
>>>>>> hopefully rather more coming soon), but has one major caveat:
>>>>>> since it's
>>>>>> pure Javascript code running in your web browser, there are
>>>>>> limitations to
>>>>>> which servers it can connect to. Specifically, it will only
>>>>>> work with DAS
>>>>>> servers that implement the W3C cross-origin resource sharing
>>>>>> model (which
>>>>>> has been discussed on this list before, but drop me a line if
>>>>>> you've got any
>>>>>> questions). What does this mean in practice? If you're adding
>>>>>> datasources
>>>>>> from the registry, things are simple because Dalliance will
>>>>>> only allow you
>>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren
>>>>>> for adding
>>>>>> some support for this in the registry). If you run your own
>>>>>> DAS servers and
>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>> compatibility
>>>>>> yourself. The latest versions of Proserver and Dazzle should
>>>>>> both be okay.
>>>>>>
>>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>>
>>>>>> Thomas Down.
>>>>>> _______________________________________________
>>>>>> DAS mailing list
>>>>>> DAS at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>
>>>>> Jonathan Warren
>>>>> Senior Developer and DAS coordinator
>>>>> blog: http://biodasman.wordpress.com/
>>>>> jw12 at sanger.ac.uk
>>>>> Ext: 2314
>>>>> Telephone: 01223 492314
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> jw12 at sanger.ac.uk
>>> Ext: 2314
>>> Telephone: 01223 492314
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> 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.
>
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 ljgarcia at ebi.ac.uk Wed Aug 4 11:14:58 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Wed, 04 Aug 2010 16:14:58 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID: <4C5983F2.7030803@ebi.ac.uk>
Sorry, I do not know what link I used but I tried again and CORS headers
are there
Thanks
On 04/08/2010 16:09, Jonathan Warren wrote:
>
> On 4 Aug 2010, at 16:03, Leyla Garcia wrote:
>
>> Thanks Andy and Jonathan,
>>
>> The CORS header is already in MyDAS and it will be available for the
>> next release, which will be soon :)
>> I will check the specification about Access-Control-Expose-Headers
>>
> Great stuff.
>
>> Jonathan, I am checking the response headers with an add-on in
>> Firefox. I tried the first URL in the dasregistry link you send me,
>> i.e. http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
>> but I do not see the Access-Control-Allow-Origin header there. So I
>> am not sure what I missing...
>>
>
> Thats odd - the first in the list is "structure" source and is run by
> the sanger which has cors in the header ( I just checked using the
> firefox plugin)- did you use the whole url I sent?
>
>> Leyla
>>
>>
>> On 04/08/2010 15:54, Jonathan Warren wrote:
>>> resp.setHeader("Access-Control-Allow-Origin", "*");
>>>
>>> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>>>
>>>> This url list 150 das sources that implement cors - see traffic
>>>> light on the end:
>>>>
>>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>>>
>>>>
>>>> You can check the headers responses for any of their valid responses.
>>>>
>>>> If you want some java code that adds this functionality to MyDAS I
>>>> can send it to you...
>>>>
>>>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>>>
>>>>> About CORS,
>>>>>
>>>>> >If you run your own DAS servers and
>>>>> >don't list them in the registry, you'll need to check for CORS
>>>>> compatibility
>>>>> >yourself. The latest versions of Proserver and Dazzle should
>>>>> both be okay.
>>>>>
>>>>> If I am not mistaken, Proserver already implements CORS headers?
>>>>> Andy, could you please send me a link of a Proserver server that
>>>>> implements this?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Leyla
>>>>>
>>>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>>>> This is very cool - I had a look the other day. Was wondering why
>>>>>> some sources could be attached and some can't....
>>>>>> Best browser experience yet by far I'd say.
>>>>>>
>>>>>> No problems about adding CORS support - for the record I'm very
>>>>>> happy to implement new capabilities testing and other suggestions
>>>>>> to the registry from anyone who cares to drop me a line.
>>>>>> Especially if it's going to enhance and promote the use of the
>>>>>> registry :)
>>>>>>
>>>>>>
>>>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>>>
>>>>>>> As some of you already know, I've been experimenting recently with a
>>>>>>> web-based DAS client for genomic data. It's still in
>>>>>>> a unashamedly prototypical state (in particular, some of the
>>>>>>> popups and
>>>>>>> configuration stuff is outright clunky, and we know it!), but
>>>>>>> we're starting
>>>>>>> to find it quite useful, and would be interested to receive more
>>>>>>> feedback.
>>>>>>> So if you're curious, you can try it here:
>>>>>>>
>>>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>>>
>>>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of
>>>>>>> DAS/1.6, and
>>>>>>> hopefully rather more coming soon), but has one major caveat:
>>>>>>> since it's
>>>>>>> pure Javascript code running in your web browser, there are
>>>>>>> limitations to
>>>>>>> which servers it can connect to. Specifically, it will only
>>>>>>> work with DAS
>>>>>>> servers that implement the W3C cross-origin resource sharing
>>>>>>> model (which
>>>>>>> has been discussed on this list before, but drop me a line if
>>>>>>> you've got any
>>>>>>> questions). What does this mean in practice? If you're adding
>>>>>>> datasources
>>>>>>> from the registry, things are simple because Dalliance will only
>>>>>>> allow you
>>>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren
>>>>>>> for adding
>>>>>>> some support for this in the registry). If you run your own DAS
>>>>>>> servers and
>>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>>> compatibility
>>>>>>> yourself. The latest versions of Proserver and Dazzle should
>>>>>>> both be okay.
>>>>>>>
>>>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>>>
>>>>>>> Thomas Down.
>>>>>>> _______________________________________________
>>>>>>> DAS mailing list
>>>>>>> DAS at lists.open-bio.org
>>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>
>>>>>> Jonathan Warren
>>>>>> Senior Developer and DAS coordinator
>>>>>> blog: http://biodasman.wordpress.com/
>>>>>> jw12 at sanger.ac.uk
>>>>>> Ext: 2314
>>>>>> Telephone: 01223 492314
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DAS mailing list
>>>>> DAS at lists.open-bio.org
>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>> Jonathan Warren
>>>> Senior Developer and DAS coordinator
>>>> blog: http://biodasman.wordpress.com/
>>>> jw12 at sanger.ac.uk
>>>> Ext: 2314
>>>> Telephone: 01223 492314
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> 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.
>>
>
> Jonathan Warren
> Senior Developer and DAS coordinator
> blog: http://biodasman.wordpress.com/
> 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 thomas.a.down at gmail.com Wed Aug 4 11:26:25 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 4 Aug 2010 16:26:25 +0100
Subject: [DAS] CORS
In-Reply-To: <3378D8DA-614B-4D56-93AD-024DAFF7F61D@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<3378D8DA-614B-4D56-93AD-024DAFF7F61D@ebi.ac.uk>
Message-ID:
Despite being a strong CORS advocate (and not just for DAS -- it'll be
beneficial for a whole raft of services), I'm actually a bit reluctant to
make it mandatory without some rather careful though.
Unrestricted CORS is, as far as I can tell, always appropriate for public
DAS servers offering data to the community. It's probably also good for
password-protected-by-publically-routable servers (although the
implementation gets a wee bit more complex in that case).
However, if you're running a DAS server behind a firewall, CORS does
potentially open you to possible security issues which wouldn't otherwise be
present. In the most security-conscious environments, people might want to
just whitelist the origins of specific clients.
How about including a link to the CORS spec and saying "implementation is
strongly encouraged", or something like that?
thomas.
On Wed, Aug 4, 2010 at 3:58 PM, Andy Jenkinson wrote:
> Since this seems to have been given the thumbs up, shall we make CORS
> support mandatory from 1.6 onwards?
>
> I suggested this when it first came up last year, but I got no replies so
> didn't put it in the spec. I suspect because it was in the middle of a
> flurry of emails about "maxbins" :)
>
> On 3 Aug 2010, at 22:28, Thomas Down wrote:
>
> > Jonathan's written a nice summary here:
> >
> > http://biodasman.wordpress.com/2010/07/20/cors/
> >
> > But briefly... it's the "official" way to work around the same-origin
> > policy (by default, browsers only allow unsigned javascript to trigger
> HTTP
> > requests to the server from which it was originally downloaded). The
> > specification is here:
> >
> > http://www.w3.org/TR/cors/
> >
> > (Please don't be too alarmed by the datestamp! The core parts have been
> > stable for > a year now, and it's well supported by Mozilla, WebKit, and
> --
> > via a slightly different API -- Internet Explorer).
> >
> > If you're running a public server and want it to be CORS accessible, all
> > that is needed is to emit the header:
> >
> > Access-Control-Allow-Origin: *
> >
> > ...and you're done.
> >
> > (If you're running password-protected DAS servers, or DAS servers hosting
> > sensitive information behind a firewall, you might want a slightly more
> > sophisticated CORS implementation. Happy to discuss if anyone is
> > interested).
> >
> > Thomas.
> >
> > On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein >wrote:
> >
> >> Someone give me a quick summary of CORS support. I want to make sure
> that
> >> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
> >> something new?)
> >>
> >> Lincoln
> >>
> >> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren
> wrote:
> >>
> >>> This is very cool - I had a look the other day. Was wondering why some
> >>> sources could be attached and some can't....
> >>> Best browser experience yet by far I'd say.
> >>>
> >>> No problems about adding CORS support - for the record I'm very happy
> to
> >>> implement new capabilities testing and other suggestions to the
> registry
> >>> from anyone who cares to drop me a line. Especially if it's going to
> enhance
> >>> and promote the use of the registry :)
> >>>
> >>>
> >>>
> >>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
> >>>
> >>> As some of you already know, I've been experimenting recently with a
> >>>> web-based DAS client for genomic data. It's still in
> >>>> a unashamedly prototypical state (in particular, some of the popups
> and
> >>>> configuration stuff is outright clunky, and we know it!), but we're
> >>>> starting
> >>>> to find it quite useful, and would be interested to receive more
> >>>> feedback.
> >>>> So if you're curious, you can try it here:
> >>>>
> >>>> http://www.biodalliance.org/human/ncbi36/
> >>>>
> >>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
> >>>> hopefully rather more coming soon), but has one major caveat: since
> it's
> >>>> pure Javascript code running in your web browser, there are
> limitations
> >>>> to
> >>>> which servers it can connect to. Specifically, it will only work with
> >>>> DAS
> >>>> servers that implement the W3C cross-origin resource sharing model
> (which
> >>>> has been discussed on this list before, but drop me a line if you've
> got
> >>>> any
> >>>> questions). What does this mean in practice? If you're adding
> >>>> datasources
> >>>> from the registry, things are simple because Dalliance will only allow
> >>>> you
> >>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
> adding
> >>>> some support for this in the registry). If you run your own DAS
> servers
> >>>> and
> >>>> don't list them in the registry, you'll need to check for CORS
> >>>> compatibility
> >>>> yourself. The latest versions of Proserver and Dazzle should both be
> >>>> okay.
> >>>>
> >>>> All comments, suggestions, and bug reports are welcome!
> >>>>
> >>>> Thomas Down.
> >>>> _______________________________________________
> >>>> DAS mailing list
> >>>> DAS at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das
> >>>>
> >>>
> >>> Jonathan Warren
> >>> Senior Developer and DAS coordinator
> >>> blog: http://biodasman.wordpress.com/
> >>> 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
> >>>
> >>
> >>
> >>
> >> --
> >> 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
> >>
> > _______________________________________________
> > DAS mailing list
> > DAS at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/das
>
>
From thomas.a.down at gmail.com Wed Aug 4 11:36:49 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 4 Aug 2010 16:36:49 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
Message-ID:
One word of warning: I've not done a lot of testing with old web browsers,
so I'd strongly recommend using Firefox 3.6, Safari 4 or 5, or an up-to-date
version of Google Chrome (Chrome auto-updates by default, so I doubt there
are many old versions in the wild).
Internet Explorer support *is* on the way, but isn't quite there yet, and
will probably be limited to Internet Explorer 9 (previous versions don't
have SVG graphics, which we're using extensively).
Thomas.
On Tue, Aug 3, 2010 at 8:41 PM, Thomas Down wrote:
> As some of you already know, I've been experimenting recently with a
> web-based DAS client for genomic data. It's still in
> a unashamedly prototypical state (in particular, some of the popups and
> configuration stuff is outright clunky, and we know it!), but we're starting
> to find it quite useful, and would be interested to receive more feedback.
> So if you're curious, you can try it here:
>
> http://www.biodalliance.org/human/ncbi36/
>
> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
> hopefully rather more coming soon), but has one major caveat: since it's
> pure Javascript code running in your web browser, there are limitations to
> which servers it can connect to. Specifically, it will only work with DAS
> servers that implement the W3C cross-origin resource sharing model (which
> has been discussed on this list before, but drop me a line if you've got any
> questions). What does this mean in practice? If you're adding datasources
> from the registry, things are simple because Dalliance will only allow you
> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
> some support for this in the registry). If you run your own DAS servers and
> don't list them in the registry, you'll need to check for CORS compatibility
> yourself. The latest versions of Proserver and Dazzle should both be okay.
>
> All comments, suggestions, and bug reports are welcome!
>
> Thomas Down.
>
From andy.jenkinson at ebi.ac.uk Wed Aug 4 12:17:50 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 4 Aug 2010 17:17:50 +0100
Subject: [DAS] CORS
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<3378D8DA-614B-4D56-93AD-024DAFF7F61D@ebi.ac.uk>
Message-ID:
Well we could specify that software must implement the procedure, and not actually require servers to accept requests from all origins?
On 4 Aug 2010, at 16:26, Thomas Down wrote:
> Despite being a strong CORS advocate (and not just for DAS -- it'll be beneficial for a whole raft of services), I'm actually a bit reluctant to make it mandatory without some rather careful though.
>
> Unrestricted CORS is, as far as I can tell, always appropriate for public DAS servers offering data to the community. It's probably also good for password-protected-by-publically-routable servers (although the implementation gets a wee bit more complex in that case).
>
> However, if you're running a DAS server behind a firewall, CORS does potentially open you to possible security issues which wouldn't otherwise be present. In the most security-conscious environments, people might want to just whitelist the origins of specific clients.
>
> How about including a link to the CORS spec and saying "implementation is strongly encouraged", or something like that?
>
> thomas.
>
> On Wed, Aug 4, 2010 at 3:58 PM, Andy Jenkinson wrote:
> Since this seems to have been given the thumbs up, shall we make CORS support mandatory from 1.6 onwards?
>
> I suggested this when it first came up last year, but I got no replies so didn't put it in the spec. I suspect because it was in the middle of a flurry of emails about "maxbins" :)
>
> On 3 Aug 2010, at 22:28, Thomas Down wrote:
>
> > Jonathan's written a nice summary here:
> >
> > http://biodasman.wordpress.com/2010/07/20/cors/
> >
> > But briefly... it's the "official" way to work around the same-origin
> > policy (by default, browsers only allow unsigned javascript to trigger HTTP
> > requests to the server from which it was originally downloaded). The
> > specification is here:
> >
> > http://www.w3.org/TR/cors/
> >
> > (Please don't be too alarmed by the datestamp! The core parts have been
> > stable for > a year now, and it's well supported by Mozilla, WebKit, and --
> > via a slightly different API -- Internet Explorer).
> >
> > If you're running a public server and want it to be CORS accessible, all
> > that is needed is to emit the header:
> >
> > Access-Control-Allow-Origin: *
> >
> > ...and you're done.
> >
> > (If you're running password-protected DAS servers, or DAS servers hosting
> > sensitive information behind a firewall, you might want a slightly more
> > sophisticated CORS implementation. Happy to discuss if anyone is
> > interested).
> >
> > Thomas.
> >
> > On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein wrote:
> >
> >> Someone give me a quick summary of CORS support. I want to make sure that
> >> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata, or
> >> something new?)
> >>
> >> Lincoln
> >>
> >> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren wrote:
> >>
> >>> This is very cool - I had a look the other day. Was wondering why some
> >>> sources could be attached and some can't....
> >>> Best browser experience yet by far I'd say.
> >>>
> >>> No problems about adding CORS support - for the record I'm very happy to
> >>> implement new capabilities testing and other suggestions to the registry
> >>> from anyone who cares to drop me a line. Especially if it's going to enhance
> >>> and promote the use of the registry :)
> >>>
> >>>
> >>>
> >>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
> >>>
> >>> As some of you already know, I've been experimenting recently with a
> >>>> web-based DAS client for genomic data. It's still in
> >>>> a unashamedly prototypical state (in particular, some of the popups and
> >>>> configuration stuff is outright clunky, and we know it!), but we're
> >>>> starting
> >>>> to find it quite useful, and would be interested to receive more
> >>>> feedback.
> >>>> So if you're curious, you can try it here:
> >>>>
> >>>> http://www.biodalliance.org/human/ncbi36/
> >>>>
> >>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
> >>>> hopefully rather more coming soon), but has one major caveat: since it's
> >>>> pure Javascript code running in your web browser, there are limitations
> >>>> to
> >>>> which servers it can connect to. Specifically, it will only work with
> >>>> DAS
> >>>> servers that implement the W3C cross-origin resource sharing model (which
> >>>> has been discussed on this list before, but drop me a line if you've got
> >>>> any
> >>>> questions). What does this mean in practice? If you're adding
> >>>> datasources
> >>>> from the registry, things are simple because Dalliance will only allow
> >>>> you
> >>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for adding
> >>>> some support for this in the registry). If you run your own DAS servers
> >>>> and
> >>>> don't list them in the registry, you'll need to check for CORS
> >>>> compatibility
> >>>> yourself. The latest versions of Proserver and Dazzle should both be
> >>>> okay.
> >>>>
> >>>> All comments, suggestions, and bug reports are welcome!
> >>>>
> >>>> Thomas Down.
> >>>> _______________________________________________
> >>>> DAS mailing list
> >>>> DAS at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das
> >>>>
> >>>
> >>> Jonathan Warren
> >>> Senior Developer and DAS coordinator
> >>> blog: http://biodasman.wordpress.com/
> >>> 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
> >>>
> >>
> >>
> >>
> >> --
> >> 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
> >>
> > _______________________________________________
> > DAS mailing list
> > DAS at lists.open-bio.org
> > http://lists.open-bio.org/mailman/listinfo/das
>
>
From thomas.a.down at gmail.com Wed Aug 4 13:39:08 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 4 Aug 2010 18:39:08 +0100
Subject: [DAS] CORS
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<3378D8DA-614B-4D56-93AD-024DAFF7F61D@ebi.ac.uk>
Message-ID:
That sounds good to me,
Thomas.
On Wed, Aug 4, 2010 at 5:17 PM, Andy Jenkinson wrote:
> Well we could specify that software must implement the procedure, and not
> actually require servers to accept requests from all origins?
>
> On 4 Aug 2010, at 16:26, Thomas Down wrote:
>
> > Despite being a strong CORS advocate (and not just for DAS -- it'll be
> beneficial for a whole raft of services), I'm actually a bit reluctant to
> make it mandatory without some rather careful though.
> >
> > Unrestricted CORS is, as far as I can tell, always appropriate for public
> DAS servers offering data to the community. It's probably also good for
> password-protected-by-publically-routable servers (although the
> implementation gets a wee bit more complex in that case).
> >
> > However, if you're running a DAS server behind a firewall, CORS does
> potentially open you to possible security issues which wouldn't otherwise be
> present. In the most security-conscious environments, people might want to
> just whitelist the origins of specific clients.
> >
> > How about including a link to the CORS spec and saying "implementation is
> strongly encouraged", or something like that?
> >
> > thomas.
> >
> > On Wed, Aug 4, 2010 at 3:58 PM, Andy Jenkinson
> wrote:
> > Since this seems to have been given the thumbs up, shall we make CORS
> support mandatory from 1.6 onwards?
> >
> > I suggested this when it first came up last year, but I got no replies so
> didn't put it in the spec. I suspect because it was in the middle of a
> flurry of emails about "maxbins" :)
> >
> > On 3 Aug 2010, at 22:28, Thomas Down wrote:
> >
> > > Jonathan's written a nice summary here:
> > >
> > > http://biodasman.wordpress.com/2010/07/20/cors/
> > >
> > > But briefly... it's the "official" way to work around the same-origin
> > > policy (by default, browsers only allow unsigned javascript to trigger
> HTTP
> > > requests to the server from which it was originally downloaded). The
> > > specification is here:
> > >
> > > http://www.w3.org/TR/cors/
> > >
> > > (Please don't be too alarmed by the datestamp! The core parts have
> been
> > > stable for > a year now, and it's well supported by Mozilla, WebKit,
> and --
> > > via a slightly different API -- Internet Explorer).
> > >
> > > If you're running a public server and want it to be CORS accessible,
> all
> > > that is needed is to emit the header:
> > >
> > > Access-Control-Allow-Origin: *
> > >
> > > ...and you're done.
> > >
> > > (If you're running password-protected DAS servers, or DAS servers
> hosting
> > > sensitive information behind a firewall, you might want a slightly more
> > > sophisticated CORS implementation. Happy to discuss if anyone is
> > > interested).
> > >
> > > Thomas.
> > >
> > > On Tue, Aug 3, 2010 at 10:21 PM, Lincoln Stein <
> lincoln.stein at gmail.com>wrote:
> > >
> > >> Someone give me a quick summary of CORS support. I want to make sure
> that
> > >> GBrowse exports DAS 1.53 with CORS (is it just the registry metadata,
> or
> > >> something new?)
> > >>
> > >> Lincoln
> > >>
> > >> On Tue, Aug 3, 2010 at 4:52 PM, Jonathan Warren
> wrote:
> > >>
> > >>> This is very cool - I had a look the other day. Was wondering why
> some
> > >>> sources could be attached and some can't....
> > >>> Best browser experience yet by far I'd say.
> > >>>
> > >>> No problems about adding CORS support - for the record I'm very happy
> to
> > >>> implement new capabilities testing and other suggestions to the
> registry
> > >>> from anyone who cares to drop me a line. Especially if it's going to
> enhance
> > >>> and promote the use of the registry :)
> > >>>
> > >>>
> > >>>
> > >>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
> > >>>
> > >>> As some of you already know, I've been experimenting recently with a
> > >>>> web-based DAS client for genomic data. It's still in
> > >>>> a unashamedly prototypical state (in particular, some of the popups
> and
> > >>>> configuration stuff is outright clunky, and we know it!), but we're
> > >>>> starting
> > >>>> to find it quite useful, and would be interested to receive more
> > >>>> feedback.
> > >>>> So if you're curious, you can try it here:
> > >>>>
> > >>>> http://www.biodalliance.org/human/ncbi36/
> > >>>>
> > >>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6,
> and
> > >>>> hopefully rather more coming soon), but has one major caveat: since
> it's
> > >>>> pure Javascript code running in your web browser, there are
> limitations
> > >>>> to
> > >>>> which servers it can connect to. Specifically, it will only work
> with
> > >>>> DAS
> > >>>> servers that implement the W3C cross-origin resource sharing model
> (which
> > >>>> has been discussed on this list before, but drop me a line if you've
> got
> > >>>> any
> > >>>> questions). What does this mean in practice? If you're adding
> > >>>> datasources
> > >>>> from the registry, things are simple because Dalliance will only
> allow
> > >>>> you
> > >>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
> adding
> > >>>> some support for this in the registry). If you run your own DAS
> servers
> > >>>> and
> > >>>> don't list them in the registry, you'll need to check for CORS
> > >>>> compatibility
> > >>>> yourself. The latest versions of Proserver and Dazzle should both
> be
> > >>>> okay.
> > >>>>
> > >>>> All comments, suggestions, and bug reports are welcome!
> > >>>>
> > >>>> Thomas Down.
> > >>>> _______________________________________________
> > >>>> DAS mailing list
> > >>>> DAS at lists.open-bio.org
> > >>>> http://lists.open-bio.org/mailman/listinfo/das
> > >>>>
> > >>>
> > >>> Jonathan Warren
> > >>> Senior Developer and DAS coordinator
> > >>> blog: http://biodasman.wordpress.com/
> > >>> 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
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> 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
> > >>
> > > _______________________________________________
> > > DAS mailing list
> > > DAS at lists.open-bio.org
> > > http://lists.open-bio.org/mailman/listinfo/das
> >
> >
>
>
From lincoln.stein at gmail.com Wed Aug 4 15:26:32 2010
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Wed, 4 Aug 2010 15:26:32 -0400
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <4C598145.5090007@ebi.ac.uk>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID:
Thanks for the pointers. I've added CORS capabilities to the GBrowse DAS
server.
Lincoln
On Wed, Aug 4, 2010 at 11:03 AM, Leyla Garcia wrote:
> Thanks Andy and Jonathan,
>
> The CORS header is already in MyDAS and it will be available for the next
> release, which will be soon :)
> I will check the specification about Access-Control-Expose-Headers
>
> Jonathan, I am checking the response headers with an add-on in Firefox. I
> tried the first URL in the dasregistry link you send me, i.e.
> http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
> but I do not see the Access-Control-Allow-Origin header there. So I am not
> sure what I missing...
>
> Leyla
>
>
>
> On 04/08/2010 15:54, Jonathan Warren wrote:
>
>> resp.setHeader("Access-Control-Allow-Origin", "*");
>>
>> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>>
>> This url list 150 das sources that implement cors - see traffic light on
>>> the end:
>>>
>>>
>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find<
>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>> >
>>>
>>>
>>> You can check the headers responses for any of their valid responses.
>>>
>>> If you want some java code that adds this functionality to MyDAS I can
>>> send it to you...
>>>
>>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>>
>>> About CORS,
>>>>
>>>> >If you run your own DAS servers and
>>>> >don't list them in the registry, you'll need to check for CORS
>>>> compatibility
>>>> >yourself. The latest versions of Proserver and Dazzle should both be
>>>> okay.
>>>>
>>>> If I am not mistaken, Proserver already implements CORS headers?
>>>> Andy, could you please send me a link of a Proserver server that
>>>> implements this?
>>>>
>>>> Thanks,
>>>>
>>>> Leyla
>>>>
>>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>>
>>>>> This is very cool - I had a look the other day. Was wondering why some
>>>>> sources could be attached and some can't....
>>>>> Best browser experience yet by far I'd say.
>>>>>
>>>>> No problems about adding CORS support - for the record I'm very happy
>>>>> to implement new capabilities testing and other suggestions to the registry
>>>>> from anyone who cares to drop me a line. Especially if it's going to enhance
>>>>> and promote the use of the registry :)
>>>>>
>>>>>
>>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>>
>>>>> As some of you already know, I've been experimenting recently with a
>>>>>> web-based DAS client for genomic data. It's still in
>>>>>> a unashamedly prototypical state (in particular, some of the popups
>>>>>> and
>>>>>> configuration stuff is outright clunky, and we know it!), but we're
>>>>>> starting
>>>>>> to find it quite useful, and would be interested to receive more
>>>>>> feedback.
>>>>>> So if you're curious, you can try it here:
>>>>>>
>>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>>
>>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>>>>> hopefully rather more coming soon), but has one major caveat: since
>>>>>> it's
>>>>>> pure Javascript code running in your web browser, there are
>>>>>> limitations to
>>>>>> which servers it can connect to. Specifically, it will only work with
>>>>>> DAS
>>>>>> servers that implement the W3C cross-origin resource sharing model
>>>>>> (which
>>>>>> has been discussed on this list before, but drop me a line if you've
>>>>>> got any
>>>>>> questions). What does this mean in practice? If you're adding
>>>>>> datasources
>>>>>> from the registry, things are simple because Dalliance will only allow
>>>>>> you
>>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>>>>>> adding
>>>>>> some support for this in the registry). If you run your own DAS
>>>>>> servers and
>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>> compatibility
>>>>>> yourself. The latest versions of Proserver and Dazzle should both be
>>>>>> okay.
>>>>>>
>>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>>
>>>>>> Thomas Down.
>>>>>> _______________________________________________
>>>>>> DAS mailing list
>>>>>> DAS at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>
>>>>>
>>>>> Jonathan Warren
>>>>> Senior Developer and DAS coordinator
>>>>> blog: http://biodasman.wordpress.com/
>>>>> jw12 at sanger.ac.uk
>>>>> Ext: 2314
>>>>> Telephone: 01223 492314
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DAS mailing list
>>>> DAS at lists.open-bio.org
>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>
>>>
>>> Jonathan Warren
>>> Senior Developer and DAS coordinator
>>> blog: http://biodasman.wordpress.com/
>>> jw12 at sanger.ac.uk
>>> Ext: 2314
>>> Telephone: 01223 492314
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> Jonathan Warren
>> Senior Developer and DAS coordinator
>> blog: http://biodasman.wordpress.com/
>> 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.
>>
>
> _______________________________________________
> 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
From thomas.a.down at gmail.com Wed Aug 4 15:35:58 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 4 Aug 2010 20:35:58 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID:
That's great Lincoln.
I don't suppose there's an updated server up somewhere that I could test
against?
Thanks,
Thomas.
On Wed, Aug 4, 2010 at 8:26 PM, Lincoln Stein wrote:
> Thanks for the pointers. I've added CORS capabilities to the GBrowse DAS
> server.
>
> Lincoln
>
> On Wed, Aug 4, 2010 at 11:03 AM, Leyla Garcia wrote:
>
> > Thanks Andy and Jonathan,
> >
> > The CORS header is already in MyDAS and it will be available for the next
> > release, which will be soon :)
> > I will check the specification about Access-Control-Expose-Headers
> >
> > Jonathan, I am checking the response headers with an add-on in Firefox. I
> > tried the first URL in the dasregistry link you send me, i.e.
> > http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
> > but I do not see the Access-Control-Allow-Origin header there. So I am
> not
> > sure what I missing...
> >
> > Leyla
> >
> >
> >
> > On 04/08/2010 15:54, Jonathan Warren wrote:
> >
> >> resp.setHeader("Access-Control-Allow-Origin", "*");
> >>
> >> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
> >>
> >> This url list 150 das sources that implement cors - see traffic light
> on
> >>> the end:
> >>>
> >>>
> >>>
> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
> <
> >>>
> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
> >>> >
> >>>
> >>>
> >>> You can check the headers responses for any of their valid responses.
> >>>
> >>> If you want some java code that adds this functionality to MyDAS I can
> >>> send it to you...
> >>>
> >>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
> >>>
> >>> About CORS,
> >>>>
> >>>> >If you run your own DAS servers and
> >>>> >don't list them in the registry, you'll need to check for CORS
> >>>> compatibility
> >>>> >yourself. The latest versions of Proserver and Dazzle should both be
> >>>> okay.
> >>>>
> >>>> If I am not mistaken, Proserver already implements CORS headers?
> >>>> Andy, could you please send me a link of a Proserver server that
> >>>> implements this?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Leyla
> >>>>
> >>>> On 03/08/2010 21:52, Jonathan Warren wrote:
> >>>>
> >>>>> This is very cool - I had a look the other day. Was wondering why
> some
> >>>>> sources could be attached and some can't....
> >>>>> Best browser experience yet by far I'd say.
> >>>>>
> >>>>> No problems about adding CORS support - for the record I'm very happy
> >>>>> to implement new capabilities testing and other suggestions to the
> registry
> >>>>> from anyone who cares to drop me a line. Especially if it's going to
> enhance
> >>>>> and promote the use of the registry :)
> >>>>>
> >>>>>
> >>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
> >>>>>
> >>>>> As some of you already know, I've been experimenting recently with a
> >>>>>> web-based DAS client for genomic data. It's still in
> >>>>>> a unashamedly prototypical state (in particular, some of the popups
> >>>>>> and
> >>>>>> configuration stuff is outright clunky, and we know it!), but we're
> >>>>>> starting
> >>>>>> to find it quite useful, and would be interested to receive more
> >>>>>> feedback.
> >>>>>> So if you're curious, you can try it here:
> >>>>>>
> >>>>>> http://www.biodalliance.org/human/ncbi36/
> >>>>>>
> >>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6,
> and
> >>>>>> hopefully rather more coming soon), but has one major caveat: since
> >>>>>> it's
> >>>>>> pure Javascript code running in your web browser, there are
> >>>>>> limitations to
> >>>>>> which servers it can connect to. Specifically, it will only work
> with
> >>>>>> DAS
> >>>>>> servers that implement the W3C cross-origin resource sharing model
> >>>>>> (which
> >>>>>> has been discussed on this list before, but drop me a line if you've
> >>>>>> got any
> >>>>>> questions). What does this mean in practice? If you're adding
> >>>>>> datasources
> >>>>>> from the registry, things are simple because Dalliance will only
> allow
> >>>>>> you
> >>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
> >>>>>> adding
> >>>>>> some support for this in the registry). If you run your own DAS
> >>>>>> servers and
> >>>>>> don't list them in the registry, you'll need to check for CORS
> >>>>>> compatibility
> >>>>>> yourself. The latest versions of Proserver and Dazzle should both
> be
> >>>>>> okay.
> >>>>>>
> >>>>>> All comments, suggestions, and bug reports are welcome!
> >>>>>>
> >>>>>> Thomas Down.
> >>>>>> _______________________________________________
> >>>>>> DAS mailing list
> >>>>>> DAS at lists.open-bio.org
> >>>>>> http://lists.open-bio.org/mailman/listinfo/das
> >>>>>>
> >>>>>
> >>>>> Jonathan Warren
> >>>>> Senior Developer and DAS coordinator
> >>>>> blog: http://biodasman.wordpress.com/
> >>>>> jw12 at sanger.ac.uk
> >>>>> Ext: 2314
> >>>>> Telephone: 01223 492314
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> DAS mailing list
> >>>> DAS at lists.open-bio.org
> >>>> http://lists.open-bio.org/mailman/listinfo/das
> >>>>
> >>>
> >>> Jonathan Warren
> >>> Senior Developer and DAS coordinator
> >>> blog: http://biodasman.wordpress.com/
> >>> jw12 at sanger.ac.uk
> >>> Ext: 2314
> >>> Telephone: 01223 492314
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Jonathan Warren
> >> Senior Developer and DAS coordinator
> >> blog: http://biodasman.wordpress.com/
> >> 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.
> >>
> >
> > _______________________________________________
> > 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
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
>
From lincoln.stein at gmail.com Wed Aug 4 16:14:08 2010
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Wed, 4 Aug 2010 16:14:08 -0400
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID:
No, it will be a while before this version is up on a live site.
Lincoln
On Wed, Aug 4, 2010 at 3:35 PM, Thomas Down wrote:
> That's great Lincoln.
>
> I don't suppose there's an updated server up somewhere that I could test
> against?
>
> Thanks,
>
> Thomas.
>
>
> On Wed, Aug 4, 2010 at 8:26 PM, Lincoln Stein wrote:
>
>> Thanks for the pointers. I've added CORS capabilities to the GBrowse DAS
>> server.
>>
>> Lincoln
>>
>> On Wed, Aug 4, 2010 at 11:03 AM, Leyla Garcia wrote:
>>
>> > Thanks Andy and Jonathan,
>> >
>> > The CORS header is already in MyDAS and it will be available for the
>> next
>> > release, which will be soon :)
>> > I will check the specification about Access-Control-Expose-Headers
>> >
>> > Jonathan, I am checking the response headers with an add-on in Firefox.
>> I
>> > tried the first URL in the dasregistry link you send me, i.e.
>> > http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
>> > but I do not see the Access-Control-Allow-Origin header there. So I am
>> not
>> > sure what I missing...
>> >
>> > Leyla
>> >
>> >
>> >
>> > On 04/08/2010 15:54, Jonathan Warren wrote:
>> >
>> >> resp.setHeader("Access-Control-Allow-Origin", "*");
>> >>
>> >> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>> >>
>> >> This url list 150 das sources that implement cors - see traffic light
>> on
>> >>> the end:
>> >>>
>> >>>
>> >>>
>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>> <
>> >>>
>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>> >>> >
>> >>>
>> >>>
>> >>> You can check the headers responses for any of their valid responses.
>> >>>
>> >>> If you want some java code that adds this functionality to MyDAS I
>> can
>> >>> send it to you...
>> >>>
>> >>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>> >>>
>> >>> About CORS,
>> >>>>
>> >>>> >If you run your own DAS servers and
>> >>>> >don't list them in the registry, you'll need to check for CORS
>> >>>> compatibility
>> >>>> >yourself. The latest versions of Proserver and Dazzle should both
>> be
>> >>>> okay.
>> >>>>
>> >>>> If I am not mistaken, Proserver already implements CORS headers?
>> >>>> Andy, could you please send me a link of a Proserver server that
>> >>>> implements this?
>> >>>>
>> >>>> Thanks,
>> >>>>
>> >>>> Leyla
>> >>>>
>> >>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>> >>>>
>> >>>>> This is very cool - I had a look the other day. Was wondering why
>> some
>> >>>>> sources could be attached and some can't....
>> >>>>> Best browser experience yet by far I'd say.
>> >>>>>
>> >>>>> No problems about adding CORS support - for the record I'm very
>> happy
>> >>>>> to implement new capabilities testing and other suggestions to the
>> registry
>> >>>>> from anyone who cares to drop me a line. Especially if it's going to
>> enhance
>> >>>>> and promote the use of the registry :)
>> >>>>>
>> >>>>>
>> >>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>> >>>>>
>> >>>>> As some of you already know, I've been experimenting recently with
>> a
>> >>>>>> web-based DAS client for genomic data. It's still in
>> >>>>>> a unashamedly prototypical state (in particular, some of the popups
>> >>>>>> and
>> >>>>>> configuration stuff is outright clunky, and we know it!), but we're
>> >>>>>> starting
>> >>>>>> to find it quite useful, and would be interested to receive more
>> >>>>>> feedback.
>> >>>>>> So if you're curious, you can try it here:
>> >>>>>>
>> >>>>>> http://www.biodalliance.org/human/ncbi36/
>> >>>>>>
>> >>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6,
>> and
>> >>>>>> hopefully rather more coming soon), but has one major caveat: since
>> >>>>>> it's
>> >>>>>> pure Javascript code running in your web browser, there are
>> >>>>>> limitations to
>> >>>>>> which servers it can connect to. Specifically, it will only work
>> with
>> >>>>>> DAS
>> >>>>>> servers that implement the W3C cross-origin resource sharing model
>> >>>>>> (which
>> >>>>>> has been discussed on this list before, but drop me a line if
>> you've
>> >>>>>> got any
>> >>>>>> questions). What does this mean in practice? If you're adding
>> >>>>>> datasources
>> >>>>>> from the registry, things are simple because Dalliance will only
>> allow
>> >>>>>> you
>> >>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>> >>>>>> adding
>> >>>>>> some support for this in the registry). If you run your own DAS
>> >>>>>> servers and
>> >>>>>> don't list them in the registry, you'll need to check for CORS
>> >>>>>> compatibility
>> >>>>>> yourself. The latest versions of Proserver and Dazzle should both
>> be
>> >>>>>> okay.
>> >>>>>>
>> >>>>>> All comments, suggestions, and bug reports are welcome!
>> >>>>>>
>> >>>>>> Thomas Down.
>> >>>>>> _______________________________________________
>> >>>>>> DAS mailing list
>> >>>>>> DAS at lists.open-bio.org
>> >>>>>> http://lists.open-bio.org/mailman/listinfo/das
>> >>>>>>
>> >>>>>
>> >>>>> Jonathan Warren
>> >>>>> Senior Developer and DAS coordinator
>> >>>>> blog: http://biodasman.wordpress.com/
>> >>>>> jw12 at sanger.ac.uk
>> >>>>> Ext: 2314
>> >>>>> Telephone: 01223 492314
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>> _______________________________________________
>> >>>> DAS mailing list
>> >>>> DAS at lists.open-bio.org
>> >>>> http://lists.open-bio.org/mailman/listinfo/das
>> >>>>
>> >>>
>> >>> Jonathan Warren
>> >>> Senior Developer and DAS coordinator
>> >>> blog: http://biodasman.wordpress.com/
>> >>> jw12 at sanger.ac.uk
>> >>> Ext: 2314
>> >>> Telephone: 01223 492314
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >> Jonathan Warren
>> >> Senior Developer and DAS coordinator
>> >> blog: http://biodasman.wordpress.com/
>> >> 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.
>> >>
>> >
>> > _______________________________________________
>> > 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
>> _______________________________________________
>> 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
From ljgarcia at ebi.ac.uk Thu Aug 5 04:42:34 2010
From: ljgarcia at ebi.ac.uk (Leyla Garcia)
Date: Thu, 05 Aug 2010 09:42:34 +0100
Subject: [DAS] Dalliance: a new genome DAS client
In-Reply-To: <4c59bfba.2337720a.65b7.459a@mx.google.com>
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
<4c59bfba.2337720a.65b7.459a@mx.google.com>
Message-ID: <4C5A797A.6080104@ebi.ac.uk>
Hi Suzanna,
Yes, I am in the DAS mailing list.
Best,
Leyla
On 04/08/2010 20:29, Suzanna Lewis wrote:
> Hi Leyla,
>
> Are you on the DAS mailing list? For some reason I only see your messages in someone else's reply, but nothing directly from you.
>
> On Aug 4, 2010, at 12:26 PM, Lincoln Stein wrote:
>
>
>> Thanks for the pointers. I've added CORS capabilities to the GBrowse DAS
>> server.
>>
>> Lincoln
>>
>> On Wed, Aug 4, 2010 at 11:03 AM, Leyla Garcia wrote:
>>
>>
>>> Thanks Andy and Jonathan,
>>>
>>> The CORS header is already in MyDAS and it will be available for the next
>>> release, which will be soon :)
>>> I will check the specification about Access-Control-Expose-Headers
>>>
>>> Jonathan, I am checking the response headers with an add-on in Firefox. I
>>> tried the first URL in the dasregistry link you send me, i.e.
>>> http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
>>> but I do not see the Access-Control-Allow-Origin header there. So I am not
>>> sure what I missing...
>>>
>>> Leyla
>>>
>>>
>>>
>>> On 04/08/2010 15:54, Jonathan Warren wrote:
>>>
>>>
>>>> resp.setHeader("Access-Control-Allow-Origin", "*");
>>>>
>>>> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>>>>
>>>> This url list 150 das sources that implement cors - see traffic light on
>>>>
>>>>> the end:
>>>>>
>>>>>
>>>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find<
>>>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>>>>
>>>>>>
>>>>>
>>>>> You can check the headers responses for any of their valid responses.
>>>>>
>>>>> If you want some java code that adds this functionality to MyDAS I can
>>>>> send it to you...
>>>>>
>>>>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>>>>
>>>>> About CORS,
>>>>>
>>>>>>
>>>>>>> If you run your own DAS servers and
>>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>>>
>>>>>> compatibility
>>>>>>
>>>>>>> yourself. The latest versions of Proserver and Dazzle should both be
>>>>>>>
>>>>>> okay.
>>>>>>
>>>>>> If I am not mistaken, Proserver already implements CORS headers?
>>>>>> Andy, could you please send me a link of a Proserver server that
>>>>>> implements this?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Leyla
>>>>>>
>>>>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>>>>
>>>>>>
>>>>>>> This is very cool - I had a look the other day. Was wondering why some
>>>>>>> sources could be attached and some can't....
>>>>>>> Best browser experience yet by far I'd say.
>>>>>>>
>>>>>>> No problems about adding CORS support - for the record I'm very happy
>>>>>>> to implement new capabilities testing and other suggestions to the registry
>>>>>>> from anyone who cares to drop me a line. Especially if it's going to enhance
>>>>>>> and promote the use of the registry :)
>>>>>>>
>>>>>>>
>>>>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>>>>
>>>>>>> As some of you already know, I've been experimenting recently with a
>>>>>>>
>>>>>>>> web-based DAS client for genomic data. It's still in
>>>>>>>> a unashamedly prototypical state (in particular, some of the popups
>>>>>>>> and
>>>>>>>> configuration stuff is outright clunky, and we know it!), but we're
>>>>>>>> starting
>>>>>>>> to find it quite useful, and would be interested to receive more
>>>>>>>> feedback.
>>>>>>>> So if you're curious, you can try it here:
>>>>>>>>
>>>>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>>>>
>>>>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/1.6, and
>>>>>>>> hopefully rather more coming soon), but has one major caveat: since
>>>>>>>> it's
>>>>>>>> pure Javascript code running in your web browser, there are
>>>>>>>> limitations to
>>>>>>>> which servers it can connect to. Specifically, it will only work with
>>>>>>>> DAS
>>>>>>>> servers that implement the W3C cross-origin resource sharing model
>>>>>>>> (which
>>>>>>>> has been discussed on this list before, but drop me a line if you've
>>>>>>>> got any
>>>>>>>> questions). What does this mean in practice? If you're adding
>>>>>>>> datasources
>>>>>>>> from the registry, things are simple because Dalliance will only allow
>>>>>>>> you
>>>>>>>> to add CORS-enabled sources (a huge thanks to Jonathan Warren for
>>>>>>>> adding
>>>>>>>> some support for this in the registry). If you run your own DAS
>>>>>>>> servers and
>>>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>>>> compatibility
>>>>>>>> yourself. The latest versions of Proserver and Dazzle should both be
>>>>>>>> okay.
>>>>>>>>
>>>>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>>>>
>>>>>>>> Thomas Down.
>>>>>>>> _______________________________________________
>>>>>>>> DAS mailing list
>>>>>>>> DAS at lists.open-bio.org
>>>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>>>
>>>>>>>>
>>>>>>> Jonathan Warren
>>>>>>> Senior Developer and DAS coordinator
>>>>>>> blog: http://biodasman.wordpress.com/
>>>>>>> jw12 at sanger.ac.uk
>>>>>>> Ext: 2314
>>>>>>> Telephone: 01223 492314
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> DAS mailing list
>>>>>> DAS at lists.open-bio.org
>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>
>>>>>>
>>>>> Jonathan Warren
>>>>> Senior Developer and DAS coordinator
>>>>> blog: http://biodasman.wordpress.com/
>>>>> jw12 at sanger.ac.uk
>>>>> Ext: 2314
>>>>> Telephone: 01223 492314
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Jonathan Warren
>>>> Senior Developer and DAS coordinator
>>>> blog: http://biodasman.wordpress.com/
>>>> 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.
>>>>
>>>>
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>>
>>
>
From jw12 at sanger.ac.uk Thu Aug 5 04:47:20 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Thu, 5 Aug 2010 09:47:20 +0100
Subject: [DAS] GBrowse as a DAS client
In-Reply-To:
References:
<3E124A50-F665-4B60-91C8-DF7F84C82BB0@sanger.ac.uk>
<4C59733D.4090304@ebi.ac.uk>
<4C598145.5090007@ebi.ac.uk>
Message-ID:
Hi Lincoln
I noticed for the GBrowse clients that I've seen online that the
option of a user adding a DAS track is not available, only the GBrowse
provider can do so in the config?
For the new GBrowse is there a plan/chance that it will use the
registry and/or allow people to specify a url directly?
There is some registry code available now that is written purely in
javascript that would make interacting with the registry very easy to
add.
On 4 Aug 2010, at 21:14, Lincoln Stein wrote:
> No, it will be a while before this version is up on a live site.
>
> Lincoln
>
> On Wed, Aug 4, 2010 at 3:35 PM, Thomas Down
> wrote:
>
>> That's great Lincoln.
>>
>> I don't suppose there's an updated server up somewhere that I could
>> test
>> against?
>>
>> Thanks,
>>
>> Thomas.
>>
>>
>> On Wed, Aug 4, 2010 at 8:26 PM, Lincoln Stein > >wrote:
>>
>>> Thanks for the pointers. I've added CORS capabilities to the
>>> GBrowse DAS
>>> server.
>>>
>>> Lincoln
>>>
>>> On Wed, Aug 4, 2010 at 11:03 AM, Leyla Garcia
>>> wrote:
>>>
>>>> Thanks Andy and Jonathan,
>>>>
>>>> The CORS header is already in MyDAS and it will be available for
>>>> the
>>> next
>>>> release, which will be soon :)
>>>> I will check the specification about Access-Control-Expose-Headers
>>>>
>>>> Jonathan, I am checking the response headers with an add-on in
>>>> Firefox.
>>> I
>>>> tried the first URL in the dasregistry link you send me, i.e.
>>>> http://cathdb.info:9000/das/cath_pdb/features?segment=5pti
>>>> but I do not see the Access-Control-Allow-Origin header there. So
>>>> I am
>>> not
>>>> sure what I missing...
>>>>
>>>> Leyla
>>>>
>>>>
>>>>
>>>> On 04/08/2010 15:54, Jonathan Warren wrote:
>>>>
>>>>> resp.setHeader("Access-Control-Allow-Origin", "*");
>>>>>
>>>>> On 4 Aug 2010, at 15:51, Jonathan Warren wrote:
>>>>>
>>>>> This url list 150 das sources that implement cors - see traffic
>>>>> light
>>> on
>>>>>> the end:
>>>>>>
>>>>>>
>>>>>>
>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>> <
>>>>>>
>>> http://www.dasregistry.org/listServices.jsp?organism=any&CSName=any&CSTypes=any&capabilities=cors&labels=any&spec=any&cmd=find
>>>>>>>
>>>>>>
>>>>>>
>>>>>> You can check the headers responses for any of their valid
>>>>>> responses.
>>>>>>
>>>>>> If you want some java code that adds this functionality to
>>>>>> MyDAS I
>>> can
>>>>>> send it to you...
>>>>>>
>>>>>> On 4 Aug 2010, at 15:03, Leyla Garcia wrote:
>>>>>>
>>>>>> About CORS,
>>>>>>>
>>>>>>>> If you run your own DAS servers and
>>>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>>> compatibility
>>>>>>>> yourself. The latest versions of Proserver and Dazzle should
>>>>>>>> both
>>> be
>>>>>>> okay.
>>>>>>>
>>>>>>> If I am not mistaken, Proserver already implements CORS headers?
>>>>>>> Andy, could you please send me a link of a Proserver server that
>>>>>>> implements this?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Leyla
>>>>>>>
>>>>>>> On 03/08/2010 21:52, Jonathan Warren wrote:
>>>>>>>
>>>>>>>> This is very cool - I had a look the other day. Was wondering
>>>>>>>> why
>>> some
>>>>>>>> sources could be attached and some can't....
>>>>>>>> Best browser experience yet by far I'd say.
>>>>>>>>
>>>>>>>> No problems about adding CORS support - for the record I'm very
>>> happy
>>>>>>>> to implement new capabilities testing and other suggestions
>>>>>>>> to the
>>> registry
>>>>>>>> from anyone who cares to drop me a line. Especially if it's
>>>>>>>> going to
>>> enhance
>>>>>>>> and promote the use of the registry :)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 3 Aug 2010, at 20:41, Thomas Down wrote:
>>>>>>>>
>>>>>>>> As some of you already know, I've been experimenting recently
>>>>>>>> with
>>> a
>>>>>>>>> web-based DAS client for genomic data. It's still in
>>>>>>>>> a unashamedly prototypical state (in particular, some of the
>>>>>>>>> popups
>>>>>>>>> and
>>>>>>>>> configuration stuff is outright clunky, and we know it!),
>>>>>>>>> but we're
>>>>>>>>> starting
>>>>>>>>> to find it quite useful, and would be interested to receive
>>>>>>>>> more
>>>>>>>>> feedback.
>>>>>>>>> So if you're curious, you can try it here:
>>>>>>>>>
>>>>>>>>> http://www.biodalliance.org/human/ncbi36/
>>>>>>>>>
>>>>>>>>> It's a fully-fledged DAS/1.53 client (with a few bits of DAS/
>>>>>>>>> 1.6,
>>> and
>>>>>>>>> hopefully rather more coming soon), but has one major
>>>>>>>>> caveat: since
>>>>>>>>> it's
>>>>>>>>> pure Javascript code running in your web browser, there are
>>>>>>>>> limitations to
>>>>>>>>> which servers it can connect to. Specifically, it will only
>>>>>>>>> work
>>> with
>>>>>>>>> DAS
>>>>>>>>> servers that implement the W3C cross-origin resource sharing
>>>>>>>>> model
>>>>>>>>> (which
>>>>>>>>> has been discussed on this list before, but drop me a line if
>>> you've
>>>>>>>>> got any
>>>>>>>>> questions). What does this mean in practice? If you're
>>>>>>>>> adding
>>>>>>>>> datasources
>>>>>>>>> from the registry, things are simple because Dalliance will
>>>>>>>>> only
>>> allow
>>>>>>>>> you
>>>>>>>>> to add CORS-enabled sources (a huge thanks to Jonathan
>>>>>>>>> Warren for
>>>>>>>>> adding
>>>>>>>>> some support for this in the registry). If you run your own
>>>>>>>>> DAS
>>>>>>>>> servers and
>>>>>>>>> don't list them in the registry, you'll need to check for CORS
>>>>>>>>> compatibility
>>>>>>>>> yourself. The latest versions of Proserver and Dazzle
>>>>>>>>> should both
>>> be
>>>>>>>>> okay.
>>>>>>>>>
>>>>>>>>> All comments, suggestions, and bug reports are welcome!
>>>>>>>>>
>>>>>>>>> Thomas Down.
>>>>>>>>> _______________________________________________
>>>>>>>>> DAS mailing list
>>>>>>>>> DAS at lists.open-bio.org
>>>>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>>>>
>>>>>>>>
>>>>>>>> Jonathan Warren
>>>>>>>> Senior Developer and DAS coordinator
>>>>>>>> blog: http://biodasman.wordpress.com/
>>>>>>>> jw12 at sanger.ac.uk
>>>>>>>> Ext: 2314
>>>>>>>> Telephone: 01223 492314
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> DAS mailing list
>>>>>>> DAS at lists.open-bio.org
>>>>>>> http://lists.open-bio.org/mailman/listinfo/das
>>>>>>>
>>>>>>
>>>>>> Jonathan Warren
>>>>>> Senior Developer and DAS coordinator
>>>>>> blog: http://biodasman.wordpress.com/
>>>>>> jw12 at sanger.ac.uk
>>>>>> Ext: 2314
>>>>>> Telephone: 01223 492314
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Jonathan Warren
>>>>> Senior Developer and DAS coordinator
>>>>> blog: http://biodasman.wordpress.com/
>>>>> 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.
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 Thu Aug 5 06:14:13 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 5 Aug 2010 11:14:13 +0100
Subject: [DAS] Fwd: [ensembl-dev] Job position - DAS developer,
Ensembl web team
References: <4CDF3A35-9790-4A4D-99BD-C70BFABD1313@sanger.ac.uk>
Message-ID: <01AFA5AE-69AC-4E1B-AA37-45AEE50AD7E1@ebi.ac.uk>
Perl people may be interested in the following Ensembl job.
Begin forwarded message:
> From: Anne Parker
> Date: 5 August 2010 10:43:13 GMT+01:00
> To: dev at ensembl.org
> Subject: [ensembl-dev] Job position - DAS developer, Ensembl web team
>
> Hi
>
> We currently have a vacancy for a Perl web developer, to work on both client and server DAS code for the main Ensembl website (www.ensembl.org).
>
> More details here:
>
> https://jobs.sanger.ac.uk/wd/plsql/wd_portal.show_job?p_web_site_id=1764&p_web_page_id=111984
>
> Please feel free to contact me if you have any questions about the position.
>
>
> Cheers
>
> Anne
>
>
> Anne Parker
> Ensembl Web Production Manager
> http://www.ensembl.org
>
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at ensembl.org
> http://lists.ensembl.org/mailman/listinfo/dev
From thomas.a.down at gmail.com Wed Aug 11 14:37:37 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 11 Aug 2010 19:37:37 +0100
Subject: [DAS] Restricting the range of an alignment query.
Message-ID:
Hi,
I'm currently looking at the spec for the DAS1.6 alignment command:
http://www.ebi.ac.uk/~aj/1.6_draft6/documents/spec.html#alignment
Suppose I'm interested in a relatively small interval of a large sequence
(ex. human NCBI36 chr22:30000000,30200000), and want to find the orthologous
segments of the mouse genome... I can certainly do:
.../das/align-oracle/alignments?query=xyzzy;subject=22
But that's potentially going to return a slew of data which could swamp
lightweight clients and all but the best network connections!
One potential solution would be to use the "cols=" filter. However, my
reading of the spec is that this is working in "alignment" coordinates,
rather than sequence coordinates. Great if you're writing a full-blown
alignment viewer and want to do some lazy-fetching, but troublesome if you
want to layer a limited about of alignment data onto a more conventional
sequence display (or, for that matter, jump into a large alignment using a
sequence feature -- for instance, a gene name -- as your reference point).
My preferred solution would be to use a "normal" DAS segment identifier. So
in my example above, I'd just query for subject?=chr22:30000000,30200000 and
get the relevant alignment blocks back straight away. However, the current
spec seems to attach a *different* meaning for subject=X:y,z (specifically,
return alignments for X plus y sequences before and z sequences after it in
a big multiple sequence alignment).
Am I missing something here?
Thomas.
PS. Also, I'd be really interested to hear from anyone else who's used the
alignment command for genome-genome alignments (or, indeed, anything bigger
than a protein), so I can coordinate and make my implementation as close as
possible to whatever's already out there.
From thomas.a.down at gmail.com Wed Aug 11 15:14:41 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 11 Aug 2010 20:14:41 +0100
Subject: [DAS] DAS1.6: coordinate systems
Message-ID:
My reading of the current spec is a bit vague about how we should refer to
coordinate systems.
There seem to be three ways to represent a CS:
- Comma-separated list, e.g. NCBI_36,Chromosome,Homo sapiens
- URI, e.g.
http://www.dasregistry.org/dasregistry/coordsys/CS_DS40
- XML, e.g.:
NCBI_36,Chromosome,Homo sapiens
The XML representation seems to be the most complete.
The URIs don't really get discussed much in the spec. Should they resolve
to anything in particular? Or should they just be treated as opaque
strings? The example I've given resolves to an HTML document with a
Vitruvian Man icon and some human-readable details, but probably isn't going
to be any help to a client.
If you restrict yourself to single-genome DAS (sequence, features, etc.),
this all works out fine -- the only interaction you need with the coordinate
system infrastructure is to filter out suitable sources from a registry, and
in that case you can either filter on the XML COORDINATES elements -- which
is fairly straightforward -- or you can ask the registry to filter for you
(using a data model which is a reasonably close match to the XML).
However, working with coordinate systems seems to be pretty much essential
once you start working with alignements, and this is where things start to
get complex.
The returned alignment XML defines the CS of each sequence in the alignment
using the comma-separated form. My assumption is that you're meant to treat
this as an opaque string and correlate it with data from a registry, but
this isn't 100% clear.
On the other hand, if you want to specify a coordinate system in the
alignment QUERY, you're supposed to provide a URI. It's not at all clear to
me what a server is supposed to be doing with this. Again, opaque string?
Is it too late to ask if there's any chance of rationalizing this (and maybe
providing a few concrete examples in the spec) before 1.6-final?
Thomas.
From andy.jenkinson at ebi.ac.uk Thu Aug 12 04:25:33 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 12 Aug 2010 09:25:33 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To:
References:
Message-ID: <97E57D65-3289-4DF8-8CB9-9A0C3A0E15A0@ebi.ac.uk>
Hi Thomas,
Unfortunately the existing use of the subject parameter was how it was designed as part of the eFamily project, very much focussed on proteins and with the alignments being their own semi-reference data type. Rob or Andreas can say more. The command is used in Pfam's alignment viewer and as mappings for SPICE, both using the full width of the alignment. The principal change between 1.53E and 1.6 is the 'cols' parameter, which at least makes it possible to retrieve sections of an alignment, but as you say this would be in the alignment's own coordinates (there's no other way to do it - which of the many sequences' coordinates would it use?). At the moment genomic alignments are purely theoretical, but 'cols' support is there in ProServer and MyDas.
As regards to what would be necessary to do what you want, I don't think we can change the subject parameter unless the existing alignment servers and clients using it can be changed, i.e. Pfam (not sure if there are others). I can't really think of another way to do it off the top of my head - the 'query' parameter has space for start/end positions and can be a sequence identifier, but this is more like 'get all alignments containing this sequence' which is not quite the same thing. It would also be a bit clunky to describe - what would "?query=alignment42:30,40" do?
Any suggestions?
Cheers,
Andy
On 11 Aug 2010, at 19:37, Thomas Down wrote:
> Hi,
>
> I'm currently looking at the spec for the DAS1.6 alignment command:
>
> http://www.ebi.ac.uk/~aj/1.6_draft6/documents/spec.html#alignment
>
> Suppose I'm interested in a relatively small interval of a large sequence
> (ex. human NCBI36 chr22:30000000,30200000), and want to find the orthologous
> segments of the mouse genome... I can certainly do:
>
> .../das/align-oracle/alignments?query=xyzzy;subject=22
>
> But that's potentially going to return a slew of data which could swamp
> lightweight clients and all but the best network connections!
>
> One potential solution would be to use the "cols=" filter. However, my
> reading of the spec is that this is working in "alignment" coordinates,
> rather than sequence coordinates. Great if you're writing a full-blown
> alignment viewer and want to do some lazy-fetching, but troublesome if you
> want to layer a limited about of alignment data onto a more conventional
> sequence display (or, for that matter, jump into a large alignment using a
> sequence feature -- for instance, a gene name -- as your reference point).
>
> My preferred solution would be to use a "normal" DAS segment identifier. So
> in my example above, I'd just query for subject?=chr22:30000000,30200000 and
> get the relevant alignment blocks back straight away. However, the current
> spec seems to attach a *different* meaning for subject=X:y,z (specifically,
> return alignments for X plus y sequences before and z sequences after it in
> a big multiple sequence alignment).
>
> Am I missing something here?
>
> Thomas.
>
>
> PS. Also, I'd be really interested to hear from anyone else who's used the
> alignment command for genome-genome alignments (or, indeed, anything bigger
> than a protein), so I can coordinate and make my implementation as close as
> possible to whatever's already out there.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From andy.jenkinson at ebi.ac.uk Thu Aug 12 05:30:08 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 12 Aug 2010 10:30:08 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID:
Hi Thomas,
Uh-oh, URIs... :)
For coordinate systems, I think the definitions of the component pieces are fairly well described. It is a pity that the species name is not given its own parameter though. The sources documentation then says: "The uri (required) attribute is a globally unique identifier for the coordinate system. It should be a fully resolvable URL providing more information about the coordinate system." This could be misleading as although the URIs _are_ resolvable, the content is not particularly machine friendly.
I am not willing to change the syntax of the coordinate system URIs out in the wild, but if you need the content returned to be machine readable we could replace the HTML content with an XML+XSLT combination. That is, "http://www.dasregistry.org/dasregistry/coordsys/CS_DS6" would look more like one of the entries in "http://www.dasregistry.org/das/coordinatesystem" to a machine, and the same as it currently does to a human. From a practical perspective though, if a client parses the XML elements from the registry's /das/coordinatesystem output, it can identify all the coordinate systems by both URI and text description. Changing the output wouldn't materially change what a client needs to do given either a URI or a comma separated string. It is always going to need to run a HTTP get and do some parsing of coordinatesystem XML. But it is certainly true that having the URI resolve to the XML is a more elegant and simple to explain system, and in any case the spec makes no mention of the fact that a client can even obtain the XML for all the coordinate systems together.
Throughout writing the 1.6 spec, URIs have always been a big problem to describe, mainly because there are lots of complications for DAS (source vs version, server vs registry namespace). URIs simply weren't given a lot of thought and explanation from the start, and it's too late to change them. In 1.6 things are a little better in that source URIs have been formalised and are more useful, without breaking the assumptions clients currently make. But I have changed the wording describing URIs a few times. I did have a large section describing URIs in general, the rules for formulating them, relative URI references etc, but in the latest drafts this is simplified so as not to confuse people (as much). It only really refers to source URIs rather than coordinate systems though, so I'm happy to add something. Could you please provide the wording and examples? Nobody ever seems to want to :)
With regards to the alignment command specifically, I wanted to use the URI for both the query and the content as they are more robust, but there was some practical reason for the existing servers that prevented us from doing so. Perhaps Rob or Andreas can comment? Again, technically it doesn't matter to the client if it has access to the coordinates XML, but it does make the spec not 'feel right' IMO. Also, if coordinate system descriptions (i.e. the comma separated string) were to change over time servers would drift and this would cause big problems for the client, but in truth plenty of stuff would break if that were to happen.
Cheers,
Andy
On 11 Aug 2010, at 20:14, Thomas Down wrote:
> My reading of the current spec is a bit vague about how we should refer to
> coordinate systems.
>
> There seem to be three ways to represent a CS:
>
> - Comma-separated list, e.g. NCBI_36,Chromosome,Homo sapiens
> - URI, e.g.
> http://www.dasregistry.org/dasregistry/coordsys/CS_DS40
> - XML, e.g.:
>
> source="Chromosome" authority="NCBI" test_range="1:1,1000"
> version="36">NCBI_36,Chromosome,Homo sapiens
>
> The XML representation seems to be the most complete.
>
> The URIs don't really get discussed much in the spec. Should they resolve
> to anything in particular? Or should they just be treated as opaque
> strings? The example I've given resolves to an HTML document with a
> Vitruvian Man icon and some human-readable details, but probably isn't going
> to be any help to a client.
>
> If you restrict yourself to single-genome DAS (sequence, features, etc.),
> this all works out fine -- the only interaction you need with the coordinate
> system infrastructure is to filter out suitable sources from a registry, and
> in that case you can either filter on the XML COORDINATES elements -- which
> is fairly straightforward -- or you can ask the registry to filter for you
> (using a data model which is a reasonably close match to the XML).
>
> However, working with coordinate systems seems to be pretty much essential
> once you start working with alignements, and this is where things start to
> get complex.
>
> The returned alignment XML defines the CS of each sequence in the alignment
> using the comma-separated form. My assumption is that you're meant to treat
> this as an opaque string and correlate it with data from a registry, but
> this isn't 100% clear.
>
> On the other hand, if you want to specify a coordinate system in the
> alignment QUERY, you're supposed to provide a URI. It's not at all clear to
> me what a server is supposed to be doing with this. Again, opaque string?
>
> Is it too late to ask if there's any chance of rationalizing this (and maybe
> providing a few concrete examples in the spec) before 1.6-final?
>
> Thomas.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From andy.jenkinson at ebi.ac.uk Thu Aug 12 05:41:54 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 12 Aug 2010 10:41:54 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To:
References:
<97E57D65-3289-4DF8-8CB9-9A0C3A0E15A0@ebi.ac.uk>
Message-ID: <88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
(ccing list, comments inline)
On 12 Aug 2010, at 09:49, Thomas Down wrote:
>
> On Thu, Aug 12, 2010 at 9:25 AM, Andy Jenkinson wrote:
> Hi Thomas,
>
> Unfortunately the existing use of the subject parameter was how it was designed as part of the eFamily project, very much focussed on proteins and with the alignments being their own semi-reference data type. Rob or Andreas can say more. The command is used in Pfam's alignment viewer and as mappings for SPICE, both using the full width of the alignment. The principal change between 1.53E and 1.6 is the 'cols' parameter, which at least makes it possible to retrieve sections of an alignment, but as you say this would be in the alignment's own coordinates (there's no other way to do it - which of the many sequences' coordinates would it use?). At the moment genomic alignments are purely theoretical, but 'cols' support is there in ProServer and MyDas.
>
> Okay, I see your point (and I'm certainly not proposing we break existing stuff), but not entirely true -- I'm running genome-genome alignment servers on my dev. machine and will be pushing at least a couple of them public once this issue is resolved. The next version of Dalliance will support alignment DAS (initially just for coordinate system mapping, but want to do a proper comparative genomics view in the future which will hopefully use much the same DAS code). Again, that's 90% working now and at this point mostly just waiting until I'm sure I'm using the alignment system properly, or at least abusing it in a somewhat-sensible manner.
OK so you're a lot further along, sounds good. A while back we were aiming to get compara alignments as DAS too (which necessitated the cols parameter).
> As regards to what would be necessary to do what you want, I don't think we can change the subject parameter unless the existing alignment servers and clients using it can be changed, i.e. Pfam (not sure if there are others). I can't really think of another way to do it off the top of my head - the 'query' parameter has space for start/end positions and can be a sequence identifier, but this is more like 'get all alignments containing this sequence' which is not quite the same thing. It would also be a bit clunky to describe - what would "?query=alignment42:30,40" do?
>
> Any suggestions?
>
> Well, the obvious thing is to couple the coordinate restrictions to the sequence to which they apply.
>
> Simplest solution I can think of would be to add:
>
> ?segment=seqName[:start,end]
>
> ...where:
>
> ?segment=P12345
>
> ...is synonymous with:
>
> ?subject=P12345 (which would still be supported),
>
> ...but...
>
> ?segment=22:30000000,30200000
>
> ...does what I want. Maybe not the cleanest solution, but I don't think it's going to horribly break anything (unless there are subtleties I'm missing here?)
>
> Thomas.
I think you're right in that it is going to need another parameter to make it work. Any objections from anyone? What would happen if you specified multiple segments which did not correspond to the same section? Return multiple blocks representing multiple horizontal sections?
From thomas.a.down at gmail.com Thu Aug 12 07:06:19 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Thu, 12 Aug 2010 12:06:19 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To: <88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
References:
<97E57D65-3289-4DF8-8CB9-9A0C3A0E15A0@ebi.ac.uk>
<88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
Message-ID:
On Thu, Aug 12, 2010 at 10:41 AM, Andy Jenkinson
wrote:
>
>
> OK so you're a lot further along, sounds good. A while back we were aiming
> to get compara alignments as DAS too (which necessitated the cols
> parameter).
By "compara alignments", you're talking about the MySQL ensembl-compara
database, right?
Is there still any interest in this on the Ensembl side? It's something I'm
going to be needing soon, too (my current chain-file-based server doesn't
handle all the cases I'm interested in).
> > As regards to what would be necessary to do what you want, I don't think
> we can change the subject parameter unless the existing alignment servers
> and clients using it can be changed, i.e. Pfam (not sure if there are
> others). I can't really think of another way to do it off the top of my head
> - the 'query' parameter has space for start/end positions and can be a
> sequence identifier, but this is more like 'get all alignments containing
> this sequence' which is not quite the same thing. It would also be a bit
> clunky to describe - what would "?query=alignment42:30,40" do?
> >
> > Any suggestions?
> >
> > Well, the obvious thing is to couple the coordinate restrictions to the
> sequence to which they apply.
> >
> > Simplest solution I can think of would be to add:
> >
> > ?segment=seqName[:start,end]
> >
> > ...where:
> >
> > ?segment=P12345
> >
> > ...is synonymous with:
> >
> > ?subject=P12345 (which would still be supported),
> >
> > ...but...
> >
> > ?segment=22:30000000,30200000
> >
> > ...does what I want. Maybe not the cleanest solution, but I don't think
> it's going to horribly break anything (unless there are subtleties I'm
> missing here?)
> >
> > Thomas.
>
> I think you're right in that it is going to need another parameter to make
> it work. Any objections from anyone? What would happen if you specified
> multiple segments which did not correspond to the same section? Return
> multiple blocks representing multiple horizontal sections?
That's the idea.
Use case for this: user is viewing 22:30000000,30200000, then zooms out.
Trigger a fetch for:
?segment=22:29900000,29999999;segment=22:30200001,30300000
...then merge the results into the working set.
Thomas.
From thomas.a.down at gmail.com Thu Aug 12 07:16:47 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Thu, 12 Aug 2010 12:16:47 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID:
On Thu, Aug 12, 2010 at 10:30 AM, Andy Jenkinson
wrote:
> Hi Thomas,
>
> Uh-oh, URIs... :)
>
> For coordinate systems, I think the definitions of the component pieces are
> fairly well described. It is a pity that the species name is not given its
> own parameter though. The sources documentation then says: "The uri
> (required) attribute is a globally unique identifier for the coordinate
> system. It should be a fully resolvable URL providing more information about
> the coordinate system." This could be misleading as although the URIs _are_
> resolvable, the content is not particularly machine friendly.
>
> I am not willing to change the syntax of the coordinate system URIs out in
> the wild, but if you need the content returned to be machine readable we
> could replace the HTML content with an XML+XSLT combination. That is, "
> http://www.dasregistry.org/dasregistry/coordsys/CS_DS6" would look more
> like one of the entries in "
> http://www.dasregistry.org/das/coordinatesystem" to a machine, and the
> same as it currently does to a human. From a practical perspective though,
> if a client parses the XML elements from the registry's
> /das/coordinatesystem output, it can identify all the coordinate systems by
> both URI and text description. Changing the output wouldn't materially
> change what a client needs to do given either a URI or a comma separated
> string. It is always going to need to run a HTTP get and do some parsing of
> coordinatesystem XML. But it is certainly true that having the URI resolve
> to the XML is a more elegant and simple to explain system, and in any case
> the spec makes no mention of the fact that a client can even obtain the XML
> for all the coordinate systems together.
>
CS URIs pointing to XML definitely seems more symmetrical.
Mentioning /das/coordinatesystem in the spec would help, too -- that's
currently rather opaque.
A few other questions (don't really have "preferred" answers to any of
these, just trying to test the boundaries):
1. What do you expect a server to do if it sees a CS URI that it
hasn't seen before?
2. If my organization has sequenced a new genome and is running some
internal DAS stuff on that while we finish annotating, etc., what URI do we
use for the coordinate system?
3. If my organization is running an internal mirror of the central
DAS registry, would I mirror the CS URIs ("
http://das.bigpharma.com/dasregistry/coordsys/CS_DS40/"). Still point to
dasregistry.org? Something else?
Thomas.
From jw12 at sanger.ac.uk Thu Aug 12 07:54:24 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Thu, 12 Aug 2010 12:54:24 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID:
On 12 Aug 2010, at 12:16, Thomas Down wrote:
> On Thu, Aug 12, 2010 at 10:30 AM, Andy Jenkinson
> wrote:
>
>> Hi Thomas,
>>
>> Uh-oh, URIs... :)
>>
>> For coordinate systems, I think the definitions of the component
>> pieces are
>> fairly well described. It is a pity that the species name is not
>> given its
>> own parameter though. The sources documentation then says: "The uri
>> (required) attribute is a globally unique identifier for the
>> coordinate
>> system. It should be a fully resolvable URL providing more
>> information about
>> the coordinate system." This could be misleading as although the
>> URIs _are_
>> resolvable, the content is not particularly machine friendly.
>>
>> I am not willing to change the syntax of the coordinate system URIs
>> out in
>> the wild, but if you need the content returned to be machine
>> readable we
>> could replace the HTML content with an XML+XSLT combination. That
>> is, "
>> http://www.dasregistry.org/dasregistry/coordsys/CS_DS6" would look
>> more
>> like one of the entries in "
>> http://www.dasregistry.org/das/coordinatesystem" to a machine, and
>> the
>> same as it currently does to a human. From a practical perspective
>> though,
>> if a client parses the XML elements from the registry's
>> /das/coordinatesystem output, it can identify all the coordinate
>> systems by
>> both URI and text description. Changing the output wouldn't
>> materially
>> change what a client needs to do given either a URI or a comma
>> separated
>> string. It is always going to need to run a HTTP get and do some
>> parsing of
>> coordinatesystem XML. But it is certainly true that having the URI
>> resolve
>> to the XML is a more elegant and simple to explain system, and in
>> any case
>> the spec makes no mention of the fact that a client can even obtain
>> the XML
>> for all the coordinate systems together.
>>
>
> CS URIs pointing to XML definitely seems more symmetrical.
>
> Mentioning /das/coordinatesystem in the spec would help, too -- that's
> currently rather opaque.
>
> A few other questions (don't really have "preferred" answers to any of
> these, just trying to test the boundaries):
>
> 1. What do you expect a server to do if it sees a CS URI that
> it
> hasn't seen before?
>
> 2. If my organization has sequenced a new genome and is
> running some
> internal DAS stuff on that while we finish annotating, etc., what
> URI do we
> use for the coordinate system?
If it were me I'd just add it to the known coordinate systems in the
registry. You can ask us to do it or run a script that will add it if
it doesn't exist already (can send you script if you want).
Having a not widely available genome in the registry wouldn't be
harmful in any way? especially if it was coming out in the future. The
only issue would be advertising an institute as working on this if
they put themselves down as the authority I guess? which maybe in
issue..
>
> 3. If my organization is running an internal mirror of the
> central
> DAS registry, would I mirror the CS URIs ("
> http://das.bigpharma.com/dasregistry/coordsys/CS_DS40/"). Still
> point to
> dasregistry.org? Something else?
If issue with authority advertising as above then mirror all sources
plus private ones and change config/hardcode change of servers/clients
to point at internal registry (which can just be a sources document
hosted locally).
???
>
> Thomas.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 thomas.a.down at gmail.com Thu Aug 12 08:05:38 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Thu, 12 Aug 2010 13:05:38 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID:
On Thu, Aug 12, 2010 at 12:54 PM, Jonathan Warren wrote:
>
> 2. If my organization has sequenced a new genome and is running some
>> internal DAS stuff on that while we finish annotating, etc., what URI do
>> we
>> use for the coordinate system?
>>
> If it were me I'd just add it to the known coordinate systems in the
> registry. You can ask us to do it or run a script that will add it if it
> doesn't exist already (can send you script if you want).
Yep, would be very interested to see that.
Thomas.
From jherrero at ebi.ac.uk Thu Aug 12 09:15:04 2010
From: jherrero at ebi.ac.uk (Javier Herrero)
Date: Thu, 12 Aug 2010 14:15:04 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To:
References:
<88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
Message-ID: <201008121415.05406.jherrero@ebi.ac.uk>
Hi Thomas
On Thursday 12 Aug 2010 12:06:19 Thomas Down wrote:
> On Thu, Aug 12, 2010 at 10:41 AM, Andy Jenkinson
>
> wrote:
> > OK so you're a lot further along, sounds good. A while back we were
> > aiming to get compara alignments as DAS too (which necessitated the cols
> > parameter).
>
> By "compara alignments", you're talking about the MySQL ensembl-compara
> database, right?
Yes, that is what we discussed some time ago.
> Is there still any interest in this on the Ensembl side? It's something
> I'm going to be needing soon, too (my current chain-file-based server
> doesn't handle all the cases I'm interested in).
I guess the interest must come from "the other side". I am quite keen on
providing alignments through DAS if people and/or DAS clients will use them
and if that is not too heavy for our servers. You can imagine that things can
go horribly wrong if one asked all 33-way EPO alignments on a chromosome at
once. This can probably be controlled in the server.
Another question is whether it is easy to fit genomic alignments into the
current dasalignment structure. I am not sure how to interpret things like
dbAccessionId, objectVersion, dbSource, etc for a genomic alignment. In other
words, should protein and genomic alignments share the same query and
response?
Javier
> > > As regards to what would be necessary to do what you want, I don't
> > > think
> >
> > we can change the subject parameter unless the existing alignment servers
> > and clients using it can be changed, i.e. Pfam (not sure if there are
> > others). I can't really think of another way to do it off the top of my
> > head - the 'query' parameter has space for start/end positions and can
> > be a sequence identifier, but this is more like 'get all alignments
> > containing this sequence' which is not quite the same thing. It would
> > also be a bit clunky to describe - what would "?query=alignment42:30,40"
> > do?
> >
> > > Any suggestions?
> > >
> > > Well, the obvious thing is to couple the coordinate restrictions to the
> >
> > sequence to which they apply.
> >
> > > Simplest solution I can think of would be to add:
> > > ?segment=seqName[:start,end]
> > >
> > > ...where:
> > > ?segment=P12345
> > >
> > > ...is synonymous with:
> > > ?subject=P12345 (which would still be supported),
> > >
> > > ...but...
> > >
> > > ?segment=22:30000000,30200000
> > >
> > > ...does what I want. Maybe not the cleanest solution, but I don't
> > > think
> >
> > it's going to horribly break anything (unless there are subtleties I'm
> > missing here?)
> >
> > > Thomas.
> >
> > I think you're right in that it is going to need another parameter to
> > make it work. Any objections from anyone? What would happen if you
> > specified multiple segments which did not correspond to the same
> > section? Return multiple blocks representing multiple horizontal
> > sections?
>
> That's the idea.
>
> Use case for this: user is viewing 22:30000000,30200000, then zooms out.
> Trigger a fetch for:
>
> ?segment=22:29900000,29999999;segment=22:30200001,30300000
>
> ...then merge the results into the working set.
>
> Thomas.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
--
Javier Herrero, PhD
Ensembl Compara Project Leader
European Bioinformatics Institute (EMBL-EBI)
Wellcome Trust Genome Campus, Hinxton
Cambridge - CB10 1SD - UK
From thomas.a.down at gmail.com Thu Aug 12 09:57:19 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Thu, 12 Aug 2010 14:57:19 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To: <201008121415.05406.jherrero@ebi.ac.uk>
References:
<88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
<201008121415.05406.jherrero@ebi.ac.uk>
Message-ID:
On Thu, Aug 12, 2010 at 2:15 PM, Javier Herrero wrote:
> Hi Thomas
>
>
> > Is there still any interest in this on the Ensembl side? It's something
> > I'm going to be needing soon, too (my current chain-file-based server
> > doesn't handle all the cases I'm interested in).
>
> I guess the interest must come from "the other side". I am quite keen on
> providing alignments through DAS if people and/or DAS clients will use them
> and if that is not too heavy for our servers.
Well, I'm very keen to get comparative data into Dalliance (
http://www.biodalliance.org/human/ncbi36/) if you haven't seen it, and an
ensembl-compara DAS server would be substantially the best way to do that.
> You can imagine that things can
> go horribly wrong if one asked all 33-way EPO alignments on a chromosome at
> once. This can probably be controlled in the server.
>
That's an interesting general question. Historically, DAS has gone more for
trusting clients to request "sensible" amounts of data (although personally,
I'd like to see a richer way of hinting to clients what "sensible" might
mean in a given context).
You could just forbid fetching alignments >1Mb or something.
Having said that, I actually think there *are* legitimate reasons for
fetching a whole chromosome worth of alignments. Firstly for clients that
want to do something other than pure data visualisation. Secondly, for a
client which wants to show a "karyotype" type view, with syntenic blocks
labeled, rather than a very detailed base-level alignment. The first one
can probably only be addressed by chunky servers and/or responsible usage
patterns, but the second one could be handled quite nicely with a very small
extension to the current DAS protocol. The current format encourages you to
represent the high-level structure of the alignment using BLOCK elements,
then fill in the fine base-level structure with CIGAR strings. Given a
server that follows this pattern, all that's needed is a flag to omit the
CIGARs and you'd have pretty-much perfect data for use in a synteny browser.
Given that the CIGAR is already optional, this ought to be pretty painless
to add.
> Another question is whether it is easy to fit genomic alignments into the
> current dasalignment structure. I am not sure how to interpret things like
> dbAccessionId, objectVersion, dbSource, etc for a genomic alignment. In
> other
> words, should protein and genomic alignments share the same query and
> response?
The response format actually fits pretty well as far as I can tell. To my
mind:
assembly name/version == dbSource (although this is kind-of
redundant with coordinate system...)
chromosome name/number == objectVersion.
Concrete example (NB. experimental server, may move, change or disappear!):
view-source:
http://www.derkholm.net:8080/das/hg18ToHg19/alignment?query=22
Because of the block/segment approach, it would be easy to generalize this
to >2 way alignments.
There may be a few minor additions that are worthwhile, but overall I'm
fairly certain this will work okay. Right now, I'm much more concerned
about the query format.
Thomas.
From andy.jenkinson at ebi.ac.uk Thu Aug 12 10:35:42 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 12 Aug 2010 15:35:42 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID: <98F09657-A419-40E5-AD78-A0D0A1877CE5@ebi.ac.uk>
On 12 Aug 2010, at 12:16, Thomas Down wrote:
>
> A few other questions (don't really have "preferred" answers to any of these, just trying to test the boundaries):
>
> 1. What do you expect a server to do if it sees a CS URI that it hasn't seen before?
I assume you mean an alignment server receiving such a URI as a parameter? If so I think there is only one realistic thing it can do right now, which is return nothing (i.e. no alignments). It is not an authority on which coordinate systems are real and which aren't, it just knows about the ones it is using. In essence it simply has no data for the requested subject because it doesn't recognise the subject. We could invent error situations for things like this, but that would make DAS more complex for little gain IMO..
> 2. If my organization has sequenced a new genome and is running some internal DAS stuff on that while we finish annotating, etc., what URI do we use for the coordinate system?
>
> 3. If my organization is running an internal mirror of the central DAS registry, would I mirror the CS URIs ("http://das.bigpharma.com/dasregistry/coordsys/CS_DS40/"). Still point to dasregistry.org? Something else?
As Jon says, I think it's easier just to create the coordinate system in the registry. At the moment you need admin privileges to do that via the interface, but I implemented a programmatic version of this wherein the registry accepts POSTed coordinate system XML (sans URI) and replies with the same (with URI included). It is restricted to allow you to create new authority/versions, but not new "segment types": so you can create "GRCh_38,Chromosome,Homo sapiens" but not "GRCh_37,wibble,Homo sapiens". We were a bit wary of opening up the ability to do the latter in fear of ending up with different spellings of the same thing, or other similar issues.
I suppose the same thing could be made available to registered users in the interface (possibly at the same time reworking it to use the web services underneath).
> Thomas.
From jw12 at sanger.ac.uk Thu Aug 12 10:45:38 2010
From: jw12 at sanger.ac.uk (Jonathan Warren)
Date: Thu, 12 Aug 2010 15:45:38 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To: <98F09657-A419-40E5-AD78-A0D0A1877CE5@ebi.ac.uk>
References:
<98F09657-A419-40E5-AD78-A0D0A1877CE5@ebi.ac.uk>
Message-ID:
On 12 Aug 2010, at 15:35, Andy Jenkinson wrote:
> On 12 Aug 2010, at 12:16, Thomas Down wrote:
>>
>> A few other questions (don't really have "preferred" answers to any
>> of these, just trying to test the boundaries):
>>
>> 1. What do you expect a server to do if it sees a CS URI
>> that it hasn't seen before?
>
> I assume you mean an alignment server receiving such a URI as a
> parameter? If so I think there is only one realistic thing it can do
> right now, which is return nothing (i.e. no alignments). It is not
> an authority on which coordinate systems are real and which aren't,
> it just knows about the ones it is using. In essence it simply has
> no data for the requested subject because it doesn't recognise the
> subject. We could invent error situations for things like this, but
> that would make DAS more complex for little gain IMO..
>
>> 2. If my organization has sequenced a new genome and is
>> running some internal DAS stuff on that while we finish annotating,
>> etc., what URI do we use for the coordinate system?
>>
>> 3. If my organization is running an internal mirror of the
>> central DAS registry, would I mirror the CS URIs ("http://das.bigpharma.com/dasregistry/coordsys/CS_DS40/
>> "). Still point to dasregistry.org? Something else?
>
> As Jon says, I think it's easier just to create the coordinate
> system in the registry. At the moment you need admin privileges to
> do that via the interface, but I implemented a programmatic version
> of this wherein the registry accepts POSTed coordinate system XML
> (sans URI) and replies with the same (with URI included). It is
> restricted to allow you to create new authority/versions, but not
> new "segment types": so you can create "GRCh_38,Chromosome,Homo
> sapiens" but not "GRCh_37,wibble,Homo sapiens". We were a bit wary
> of opening up the ability to do the latter in fear of ending up with
> different spellings of the same thing, or other similar issues.
>
> I suppose the same thing could be made available to registered users
> in the interface (possibly at the same time reworking it to use the
> web services underneath).
>
This functionality is currently available in the interface for admin
users.
>> Thomas.
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
Jonathan Warren
Senior Developer and DAS coordinator
blog: http://biodasman.wordpress.com/
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 andreas at sdsc.edu Thu Aug 12 11:22:59 2010
From: andreas at sdsc.edu (Andreas Prlic)
Date: Thu, 12 Aug 2010 08:22:59 -0700
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To:
References:
<88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
<201008121415.05406.jherrero@ebi.ac.uk>
Message-ID:
Just to add my 0.02$: I have seen the spec always as a tool to write
applications. If the spec does not support a new type of application
it should get modified. I like pragmatic approach of coupling the
coordinate restrictions to the sequence to which they apply...
Andreas
--
-----------------------------------------------------------------------
Dr. Andreas Prlic
Senior Scientist, RCSB PDB Protein Data Bank
University of California, San Diego
(+1) 858.246.0526
-----------------------------------------------------------------------
From andreas at sdsc.edu Thu Aug 12 11:29:38 2010
From: andreas at sdsc.edu (Andreas Prlic)
Date: Thu, 12 Aug 2010 08:29:38 -0700
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID:
> With regards to the alignment command specifically, I wanted to use the URI for both the query and the content as they are more robust, but there was some practical reason for the existing servers that prevented us from doing so. Perhaps Rob or Andreas can comment?
Do you mean that if you have a URI as part of a URL parameter, you
need to HTTP escape it?
Andreas
--
-----------------------------------------------------------------------
Dr. Andreas Prlic
Senior Scientist, RCSB PDB Protein Data Bank
University of California, San Diego
(+1) 858.246.0526
-----------------------------------------------------------------------
From andy.jenkinson at ebi.ac.uk Thu Aug 12 12:28:27 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Thu, 12 Aug 2010 17:28:27 +0100
Subject: [DAS] DAS1.6: coordinate systems
In-Reply-To:
References:
Message-ID: <39B1538B-947D-4CCB-9759-0EFFD438AB38@ebi.ac.uk>
On 12 Aug 2010, at 16:29, Andreas Prlic wrote:
>> With regards to the alignment command specifically, I wanted to use the URI for both the query and the content as they are more robust, but there was some practical reason for the existing servers that prevented us from doing so. Perhaps Rob or Andreas can comment?
>
> Do you mean that if you have a URI as part of a URL parameter, you
> need to HTTP escape it?
I'm not sure if you need to escape or not, I don't think so.
But what I meant is that I wanted the XML content to contain the URI instead of the comma separated description, i.e.:
instead of:
I went through the alignment command with Rob when drawing up the 1.6 spec, and this was one of the issues we discussed. The 1.53E documentation does not say what should be used in this field. Rob preferred to use the comma separated version, probably because servers were already doing it that way.
However, the coordinate system can also be specified in the "subjectcoordsys" query parameter (to help when subjects within an alignment have the same name but different coordinate systems):
/das/mysource/alignment?query=alignid&subject=seqid&subjectcoordsys=http://www.dasregistry.org/dasregistry/coordsys/CS_DS123
I remember this being added to 1.53E, but again it is not fully described in the 1.53E documentation. In the 1.6 specification I've written that it should be the URI, but I can't remember why I wrote it this way - it could be a mistake, or there could be servers/clients doing it this way.
From thomas.a.down at gmail.com Thu Aug 12 16:50:42 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Thu, 12 Aug 2010 21:50:42 +0100
Subject: [DAS] Restricting the range of an alignment query.
In-Reply-To: <88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
References:
<97E57D65-3289-4DF8-8CB9-9A0C3A0E15A0@ebi.ac.uk>
<88D5E515-89B1-4BF8-99AC-6DCD0B4A82B0@ebi.ac.uk>
Message-ID:
Just to follow up briefly, here's a somewhat usable example use of genome
alignment DAS. (NB, requires Firefox 3.6+ or recent-ish version of Safari or
Google Chrome).
1. Go to http://www.biodalliance.org/human/GRCh37/
2. Click on the "Add tracks" button (left hand end of the toolbar).
3. Click over to the "NCBI36" tab.
4. Select some datasources from the registry and click "Add".
Behind the scenes, your browser will be fetching relevant parts of the
NCBI36 vs. GRCh37 alignment via DAS, then using this to re-map features on
the fly.
(Currently the alignment-fetching depends on what I fear is a slightly
non-standard usage of the query= parameter. But once we've got a good
alternative to that, we can do the whole process using pure DAS).
Thomas.
From awitney at sgul.ac.uk Tue Aug 17 11:49:31 2010
From: awitney at sgul.ac.uk (Adam Witney)
Date: Tue, 17 Aug 2010 16:49:31 +0100
Subject: [DAS] DAS and bacterial genomes
Message-ID: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
Hi,
What would be the best approach to use DAS with bacterial genomes? I can't seem to find any coordinate systems for these organisms in the Registry.
Thanks for any advice
Adam
From andy.jenkinson at ebi.ac.uk Tue Aug 17 13:07:48 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Tue, 17 Aug 2010 18:07:48 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
Message-ID: <486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
Hi Adam,
There are no coordinate systems yet as nobody has yet been brave enough to start using DAS with bacteria in anger. Eugene at Ensembl Genomes will have an interest in doing this, but they have issues with matching up their species/strain names with the NCBI taxonomy upon which DAS's coordinates are based. In essence if you will need to name the coordinate systems after which they will need to be added to the registry.
For example when Ensembl Genomes manage to do this, the coordinate systems might end up looking like:
EB_1,Chromosome,Shigella flexneri 2a str. 301
EB_1,Plasmid,Shigella flexneri 2a str. 301
This is for a specific shigella strain with taxonomy ID 198214. The authority and version parts of the DAS coordinate system are somewhat arbitrarily named, ideally they would be a standard that is used by the rest of the community for interoperability purposes.
What exactly is it you'd like to be able to do? How many species' are we talking about?
The reason I ask is that getting these coordinate systems into the DAS registry does require some work. Some of this is on the registry's side, but depending where your data come from there may be issues with identifying the correct coordinate system details such that others can reuse them meaningfully. To use the example above, Ensembl Genomes give the "301" strain a different name from NCBI and use the taxonomy ID not for the strain but for the parent species (Shigella flexneri). In fact the 2457T strain also uses the same taxonomy ID, which isn't helpful. Given the number of species', this adds up to a major headache.
Cheers,
Andy
On 17 Aug 2010, at 16:49, Adam Witney wrote:
> Hi,
>
> What would be the best approach to use DAS with bacterial genomes? I can't seem to find any coordinate systems for these organisms in the Registry.
>
> Thanks for any advice
>
> Adam
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From awitney at sgul.ac.uk Wed Aug 18 04:52:35 2010
From: awitney at sgul.ac.uk (Adam Witney)
Date: Wed, 18 Aug 2010 09:52:35 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
Message-ID:
Hi Andy,
Yes I am aware of the some of the idiosyncrasies of the Ensembl Genomes naming conventions. But is there a reason that the DAS registry should be constrained by Ensembl Genomes? Could the Registry entry refer to a specific taxonomy iD and its corresponding entry in EG, despite EG using a different taxonomy ID?
I'd like to be able to export our microarray designs and data via DAS for others to use (including EnsemblBacteria). This if for 16 or so species with multiple strains thereof.
cheers
Adam
On 17 Aug 2010, at 18:07, Andy Jenkinson wrote:
> Hi Adam,
>
> There are no coordinate systems yet as nobody has yet been brave enough to start using DAS with bacteria in anger. Eugene at Ensembl Genomes will have an interest in doing this, but they have issues with matching up their species/strain names with the NCBI taxonomy upon which DAS's coordinates are based. In essence if you will need to name the coordinate systems after which they will need to be added to the registry.
>
> For example when Ensembl Genomes manage to do this, the coordinate systems might end up looking like:
> EB_1,Chromosome,Shigella flexneri 2a str. 301
> EB_1,Plasmid,Shigella flexneri 2a str. 301
>
> This is for a specific shigella strain with taxonomy ID 198214. The authority and version parts of the DAS coordinate system are somewhat arbitrarily named, ideally they would be a standard that is used by the rest of the community for interoperability purposes.
>
> What exactly is it you'd like to be able to do? How many species' are we talking about?
>
> The reason I ask is that getting these coordinate systems into the DAS registry does require some work. Some of this is on the registry's side, but depending where your data come from there may be issues with identifying the correct coordinate system details such that others can reuse them meaningfully. To use the example above, Ensembl Genomes give the "301" strain a different name from NCBI and use the taxonomy ID not for the strain but for the parent species (Shigella flexneri). In fact the 2457T strain also uses the same taxonomy ID, which isn't helpful. Given the number of species', this adds up to a major headache.
>
> Cheers,
> Andy
>
> On 17 Aug 2010, at 16:49, Adam Witney wrote:
>
>> Hi,
>>
>> What would be the best approach to use DAS with bacterial genomes? I can't seem to find any coordinate systems for these organisms in the Registry.
>>
>> Thanks for any advice
>>
>> Adam
>> _______________________________________________
>> DAS mailing list
>> DAS at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/das
>
From birney at ebi.ac.uk Wed Aug 18 05:30:32 2010
From: birney at ebi.ac.uk (Ewan Birney)
Date: Wed, 18 Aug 2010 10:30:32 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To:
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
Message-ID: <4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
On 18 Aug 2010, at 09:52, Adam Witney wrote:
>
> Hi Andy,
>
> Yes I am aware of the some of the idiosyncrasies of the Ensembl
> Genomes naming conventions. But is there a reason that the DAS
> registry should be constrained by Ensembl Genomes? Could the
> Registry entry refer to a specific taxonomy iD and its corresponding
> entry in EG, despite EG using a different taxonomy ID?
>
> I'd like to be able to export our microarray designs and data via
> DAS for others to use (including EnsemblBacteria). This if for 16 or
> so species with multiple strains thereof.
>
Just to say that I think we should get this as straight as we can;
just to
state the obvious - EG is not trying to be deliberately complex here,
it is
just that the concept of "one taxid == one species == one assembly
series" just
breaks down in bacteria.
I've brought in the three key people here on the EG side - Eugene
(does the web
side of this); Dan (main data production manager) and Paul Kersey (the
EG PI) -
some of them are on holiday now, but I suggest perhaps setting up a
phone
conference (and/or Adam could you come for a visit?) to get this as
straight as
we can - I suspect there will both be short term fixes and more longer
term
infrastructural fixes here.
> cheers
>
> Adam
>
>
> On 17 Aug 2010, at 18:07, Andy Jenkinson wrote:
>
>> Hi Adam,
>>
>> There are no coordinate systems yet as nobody has yet been brave
>> enough to start using DAS with bacteria in anger. Eugene at Ensembl
>> Genomes will have an interest in doing this, but they have issues
>> with matching up their species/strain names with the NCBI taxonomy
>> upon which DAS's coordinates are based. In essence if you will need
>> to name the coordinate systems after which they will need to be
>> added to the registry.
>>
>> For example when Ensembl Genomes manage to do this, the coordinate
>> systems might end up looking like:
>> EB_1,Chromosome,Shigella flexneri 2a str. 301
>> EB_1,Plasmid,Shigella flexneri 2a str. 301
>>
>> This is for a specific shigella strain with taxonomy ID 198214. The
>> authority and version parts of the DAS coordinate system are
>> somewhat arbitrarily named, ideally they would be a standard that
>> is used by the rest of the community for interoperability purposes.
>>
>> What exactly is it you'd like to be able to do? How many species'
>> are we talking about?
>>
>> The reason I ask is that getting these coordinate systems into the
>> DAS registry does require some work. Some of this is on the
>> registry's side, but depending where your data come from there may
>> be issues with identifying the correct coordinate system details
>> such that others can reuse them meaningfully. To use the example
>> above, Ensembl Genomes give the "301" strain a different name from
>> NCBI and use the taxonomy ID not for the strain but for the parent
>> species (Shigella flexneri). In fact the 2457T strain also uses the
>> same taxonomy ID, which isn't helpful. Given the number of
>> species', this adds up to a major headache.
>>
>> Cheers,
>> Andy
>>
>> On 17 Aug 2010, at 16:49, Adam Witney wrote:
>>
>>> Hi,
>>>
>>> What would be the best approach to use DAS with bacterial genomes?
>>> I can't seem to find any coordinate systems for these organisms in
>>> the Registry.
>>>
>>> Thanks for any advice
>>>
>>> Adam
>>> _______________________________________________
>>> DAS mailing list
>>> DAS at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/das
>>
>
>
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From thomas.a.down at gmail.com Wed Aug 18 05:35:36 2010
From: thomas.a.down at gmail.com (Thomas Down)
Date: Wed, 18 Aug 2010 10:35:36 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
Message-ID:
On Wed, Aug 18, 2010 at 10:30 AM, Ewan Birney wrote:
>
> On 18 Aug 2010, at 09:52, Adam Witney wrote:
>
>
>> Hi Andy,
>>
>> Yes I am aware of the some of the idiosyncrasies of the Ensembl Genomes
>> naming conventions. But is there a reason that the DAS registry should be
>> constrained by Ensembl Genomes? Could the Registry entry refer to a specific
>> taxonomy iD and its corresponding entry in EG, despite EG using a different
>> taxonomy ID?
>>
>> I'd like to be able to export our microarray designs and data via DAS for
>> others to use (including EnsemblBacteria). This if for 16 or so species with
>> multiple strains thereof.
>>
>>
> Just to say that I think we should get this as straight as we can; just to
> state the obvious - EG is not trying to be deliberately complex here, it is
> just that the concept of "one taxid == one species == one assembly series"
> just
> breaks down in bacteria.
>
>
> I've brought in the three key people here on the EG side - Eugene (does the
> web
> side of this); Dan (main data production manager) and Paul Kersey (the EG
> PI) -
> some of them are on holiday now, but I suggest perhaps setting up a phone
> conference (and/or Adam could you come for a visit?) to get this as
> straight as
> we can - I suspect there will both be short term fixes and more longer term
> infrastructural fixes here.
The DAS coordinate system scheme already handles multiple assemblies for a
given taxon fairly well (via the "authority" part). So it sounds like the
main thing that's missing is a sensible way of distinguishing between
strains. Given that the CSs are already defined by XML elements with
multiple attributes (many of them optional), would adding an (also optional,
of course) strain attribute get things 95% of the way there?
Thomas.
From birney at ebi.ac.uk Wed Aug 18 05:52:06 2010
From: birney at ebi.ac.uk (Ewan Birney)
Date: Wed, 18 Aug 2010 10:52:06 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To:
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
Message-ID: <5CDE0B00-9FC5-481F-AD70-D25467D0C38A@ebi.ac.uk>
>>
>>
>> I've brought in the three key people here on the EG side - Eugene
>> (does the
>> web
>> side of this); Dan (main data production manager) and Paul Kersey
>> (the EG
>> PI) -
>> some of them are on holiday now, but I suggest perhaps setting up a
>> phone
>> conference (and/or Adam could you come for a visit?) to get this as
>> straight as
>> we can - I suspect there will both be short term fixes and more
>> longer term
>> infrastructural fixes here.
>
>
> The DAS coordinate system scheme already handles multiple assemblies
> for a
> given taxon fairly well (via the "authority" part). So it sounds
> like the
> main thing that's missing is a sensible way of distinguishing between
> strains. Given that the CSs are already defined by XML elements with
> multiple attributes (many of them optional), would adding an (also
> optional,
> of course) strain attribute get things 95% of the way there?
>
I dont think this quite works; the whole thing goes fractal here in
that multiple
groups assign "their" assemblies to the same strain id so you have hte
same problem,
just one level lower (I think).
At the last EBI/NCBI meeting we got to more clarity on there being
tracking identifiers
for assembly series. I think this is the long term solution. But it
needs to be pushed
out to bacteria, systems in place, and populated.
In the meantime we should do something practical to at least allow DAS
servers to be
mounted against EG web sites (I think this is Adam's use case).
...but I am not the expert here. Each time I think this is simple
it .... doesn't end up
that way.
> Thomas.
> _______________________________________________
> DAS mailing list
> DAS at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/das
From awitney at sgul.ac.uk Wed Aug 18 06:02:44 2010
From: awitney at sgul.ac.uk (Adam Witney)
Date: Wed, 18 Aug 2010 11:02:44 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
Message-ID: <6EC863C7-F241-4CAD-9613-CDCC35E8074A@sgul.ac.uk>
>> Yes I am aware of the some of the idiosyncrasies of the Ensembl Genomes naming conventions. But is there a reason that the DAS registry should be constrained by Ensembl Genomes? Could the Registry entry refer to a specific taxonomy iD and its corresponding entry in EG, despite EG using a different taxonomy ID?
>>
>> I'd like to be able to export our microarray designs and data via DAS for others to use (including EnsemblBacteria). This if for 16 or so species with multiple strains thereof.
>>
>
> Just to say that I think we should get this as straight as we can; just to
> state the obvious - EG is not trying to be deliberately complex here, it is
> just that the concept of "one taxid == one species == one assembly series" just
> breaks down in bacteria.
Could it be treated as "one taxid == one strain == one assembly"?
> I've brought in the three key people here on the EG side - Eugene (does the web
> side of this); Dan (main data production manager) and Paul Kersey (the EG PI) -
> some of them are on holiday now, but I suggest perhaps setting up a phone
> conference (and/or Adam could you come for a visit?) to get this as straight as
> we can - I suspect there will both be short term fixes and more longer term
> infrastructural fixes here.
I'm happy to help any way I can. I am registered on the Ensembl developers workshop next month so could chat to you guys then?
thanks
adam
From biopython at maubp.freeserve.co.uk Wed Aug 18 07:23:56 2010
From: biopython at maubp.freeserve.co.uk (Peter)
Date: Wed, 18 Aug 2010 12:23:56 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <6EC863C7-F241-4CAD-9613-CDCC35E8074A@sgul.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
<6EC863C7-F241-4CAD-9613-CDCC35E8074A@sgul.ac.uk>
Message-ID:
On Wed, Aug 18, 2010 at 11:02 AM, Adam Witney wrote:
>
>>
>> Just to say that I think we should get this as straight as we can; just to
>> state the obvious - EG is not trying to be deliberately complex here, it is
>> just that the concept of "one taxid == one species == one assembly series" just
>> breaks down in bacteria.
>
> Could it be treated as "one taxid == one strain == one assembly"?
I'm sticking my oar in here, and probably this is obvious, but anyway...
Surely it has to be "one taxid == one strain == multiple assemblies"? And this
isn't just for Bacteria, but all organisms. After all, "the" human sequence
has already gone through several revisions (hg18 and hg19 being the latest).
Even things like the E coli K12 sequence have gone through multiple revisions
after publication.
What about multiple individual genomes from the same taxid? What I am
thinking of here is different human genomes - do we call Craig Ventor a
strain of human with his own taxid? That doesn't seem like it will scale well ;)
Would we have an extra level here,
i.e. one taxid == one strain == multiple individuals,
one individual == multiple assemblies
Peter
From andy.jenkinson at ebi.ac.uk Wed Aug 18 08:23:54 2010
From: andy.jenkinson at ebi.ac.uk (Andy Jenkinson)
Date: Wed, 18 Aug 2010 13:23:54 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <6EC863C7-F241-4CAD-9613-CDCC35E8074A@sgul.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
<6EC863C7-F241-4CAD-9613-CDCC35E8074A@sgul.ac.uk>
Message-ID:
>> I've brought in the three key people here on the EG side - Eugene (does the web
>> side of this); Dan (main data production manager) and Paul Kersey (the EG PI) -
>> some of them are on holiday now, but I suggest perhaps setting up a phone
>> conference (and/or Adam could you come for a visit?) to get this as straight as
>> we can - I suspect there will both be short term fixes and more longer term
>> infrastructural fixes here.
>
> I'm happy to help any way I can. I am registered on the Ensembl developers workshop next month so could chat to you guys then?
>
> thanks
>
> adam
I think this is sensible. I've been through this topic a few times with Eugene and I know it is not simple, but I would really like to see this resolved and I do have my own ideas of options to do it. I feel we need to get clear on what the issues are and formulate a plan, and it's much easier to do in person.
From lincoln.stein at gmail.com Wed Aug 18 15:25:29 2010
From: lincoln.stein at gmail.com (Lincoln Stein)
Date: Wed, 18 Aug 2010 15:25:29 -0400
Subject: [DAS] DAS and bacterial genomes
In-Reply-To: <4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
Message-ID:
It sounds to me as though the DAS source metadata needs just one additional
field to indicate the strain, isolate or individual, making the hierarchy:
taxid -> strain/isolate/individual id -> assembly
(the taxid and the assembly are already in DAS) Is there a definitive
repository of isolate IDs that could be used for this purpose?
As mentioned elsewhere in this thread, the problem of distinguishing an
individual from its taxon is not limited to bacteria. Does the 1000 genomes
project use the assembly as a surrogate for isolate/individual?
Lincoln
On Wed, Aug 18, 2010 at 5:30 AM, Ewan Birney wrote:
>
> On 18 Aug 2010, at 09:52, Adam Witney wrote:
>
>
>> Hi Andy,
>>
>> Yes I am aware of the some of the idiosyncrasies of the Ensembl Genomes
>> naming conventions. But is there a reason that the DAS registry should be
>> constrained by Ensembl Genomes? Could the Registry entry refer to a specific
>> taxonomy iD and its corresponding entry in EG, despite EG using a different
>> taxonomy ID?
>>
>> I'd like to be able to export our microarray designs and data via DAS for
>> others to use (including EnsemblBacteria). This if for 16 or so species with
>> multiple strains thereof.
>>
>>
> Just to say that I think we should get this as straight as we can; just to
> state the obvious - EG is not trying to be deliberately complex here, it is
> just that the concept of "one taxid == one species == one assembly series"
> just
> breaks down in bacteria.
>
>
> I've brought in the three key people here on the EG side - Eugene (does the
> web
> side of this); Dan (main data production manager) and Paul Kersey (the EG
> PI) -
> some of them are on holiday now, but I suggest perhaps setting up a phone
> conference (and/or Adam could you come for a visit?) to get this as
> straight as
> we can - I suspect there will both be short term fixes and more longer term
> infrastructural fixes here.
>
>
>
> cheers
>>
>> Adam
>>
>>
>> On 17 Aug 2010, at 18:07, Andy Jenkinson wrote:
>>
>> Hi Adam,
>>>
>>> There are no coordinate systems yet as nobody has yet been brave enough
>>> to start using DAS with bacteria in anger. Eugene at Ensembl Genomes will
>>> have an interest in doing this, but they have issues with matching up their
>>> species/strain names with the NCBI taxonomy upon which DAS's coordinates are
>>> based. In essence if you will need to name the coordinate systems after
>>> which they will need to be added to the registry.
>>>
>>> For example when Ensembl Genomes manage to do this, the coordinate
>>> systems might end up looking like:
>>> EB_1,Chromosome,Shigella flexneri 2a str. 301
>>> EB_1,Plasmid,Shigella flexneri 2a str. 301
>>>
>>> This is for a specific shigella strain with taxonomy ID 198214. The
>>> authority and version parts of the DAS coordinate system are somewhat
>>> arbitrarily named, ideally they would be a standard that is used by the rest
>>> of the community for interoperability purposes.
>>>
>>> What exactly is it you'd like to be able to do? How many species' are we
>>> talking about?
>>>
>>> The reason I ask is that getting these coordinate systems into the DAS
>>> registry does require some work. Some of this is on the registry's side, but
>>> depending where your data come from there may be issues with identifying the
>>> correct coordinate system details such that others can reuse them
>>> meaningfully. To use the example above, Ensembl Genomes give the "301"
>>> strain a different name from NCBI and use the taxonomy ID not for the strain
>>> but for the parent species (Shigella flexneri). In fact the 2457T strain
>>> also uses the same taxonomy ID, which isn't helpful. Given the number of
>>> species', this adds up to a major headache.
>>>
>>> Cheers,
>>> Andy
>>>
>>> On 17 Aug 2010, at 16:49, Adam Witney wrote:
>>>
>>> Hi,
>>>>
>>>> What would be the best approach to use DAS with bacterial genomes? I
>>>> can't seem to find any coordinate systems for these organisms in the
>>>> Registry.
>>>>
>>>> Thanks for any advice
>>>>
>>>> Adam
>>>> _______________________________________________
>>>> 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
>>
>
> _______________________________________________
> 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
From awitney at sgul.ac.uk Wed Aug 18 15:47:30 2010
From: awitney at sgul.ac.uk (Adam Witney)
Date: Wed, 18 Aug 2010 20:47:30 +0100
Subject: [DAS] DAS and bacterial genomes
In-Reply-To:
References: <1C04AD6A-43A2-42E7-8C32-AC2DE6918C1D@sgul.ac.uk>
<486250E2-BA0E-4321-8E4D-283B5A5F4881@ebi.ac.uk>
<4A57341B-BB29-4291-A61B-D6C314F846C4@ebi.ac.uk>
Message-ID: