[BioRuby] Ensembl API

[jan aerts (RI)]

Toshiaki,

Your idea of a directory structure as this seems a good choice.
  /bioruby-annex/rails/plugins <- for Rails' script/plugin source
  /bioruby-annex/project1/
  /bioruby-annex/project2/
    :

OK if I add a subdirectory for 'ensembl_api'? (so that would be:
/bioruby-annex/ensembl_api/)

jan.

-----Original Message-----
From: Toshiaki Katayama [mailto:ktym at hgc.jp] 
Sent: 10 May 2007 12:43
To: jan aerts (RI)
Cc: BioRubyML
Subject: Re: [BioRuby] Ensembl API

Jan,

You are added as a annex developer.

> I noticed that the bioruby-annex repository is for bioruby *rails* 
> plugins. However, the Ensembl API would have nothing to do with rails

When I discussed with Nakao-san previously, we have agreed to include
any Rails (or ActiveRecord etc.) dependent bioinformatics projects in
the bioruby-annex repository (maybe we need to refine

The purpose is

1. The number of codes which depend on Rails related libraries
   is increasing, but we have not yet decided how to integrate
   such modules in BioRuby.

2. We thought correcting various add-ons to BioRuby in one place
   might be useful (so that users can find your bioinformatics
   modules easily, and/or some of them might be integrated into
   core BioRuby library in the future).

> (apart from the fact that it uses ActiveRecord in the background).

So, I thought your project is appropriate to be included.

> This might get confusing for possible users.

Yes, we may need to re-write our project description to clarify.
Volunteers?

As the bioruby-annex seems to be functioning now, we need to discuss
some rules for how to develop, release, and use sub products in it.

My idea is still vague, but how about to have codes in SVN as

  /bioruby-annex/rails/plugins <- for Rails' script/plugin source
  /bioruby-annex/project1/
  /bioruby-annex/project2/
    :

and each sub projects will release the package as a gem (or tar.gz) file
prefixed with 'bioruby-' or 'bioruby-annex-' so that, for instance, you
could release

  bioruby-ensembl-api-1.0.gem

for downlaod from

  http://rubyforge.org/projects/bioruby-annex/

Toshiaki

On 2007/05/10, at 19:34, jan aerts (RI) wrote:

> Toshiaki,
>
> I noticed that the bioruby-annex repository is for bioruby *rails* 
> plugins. However, the Ensembl API would have nothing to do with rails 
> (apart from the fact that it uses ActiveRecord in the background).
> This might get confusing for possible users.
>
> jan. 
>
> -----Original Message-----
> From: Toshiaki Katayama [mailto:ktym at hgc.jp]
> Sent: 10 May 2007 11:14
> To: jan aerts (RI)
> Cc: Michael Han; bioruby at lists.open-bio.org
> Subject: Re: [BioRuby] Ensembl API
>
> Jan,
>
> In that case, I would like you to consider to use the rubyforge 
> repository 'bioruby-annex' which Nakao-san had set up.
>
>   http://lists.open-bio.org/pipermail/bioruby/2007-April/000355.html
>
> When your modules matured and we, core developers, have decided how to

> integrate Rails dependent modules in BioRuby, you can put them in the 
> BioRuby distribution.
>
> Toshiaki
>
> On 2007/05/10, at 18:09, jan aerts (RI) wrote:
>
>> I actually just started working on this API last night (in between 
>> some deadlines I got to catch), so haven't gotten so far as to think 
>> about caching. I'm basically working through the perl API tutorial
>> (http://www.ensembl.org/info/software/core/core_tutorial.html) and 
>> try
>
>> to implement all those examples. (At the moment, I'm at the bit that 
>> says "Break chromosomal slices into smaller 100k component 
>> slices"...)
>>
>> Some hurdles that I see coming are the caching and projecting 
>> features
>
>> from one coord system to another. We'll see what happens when we get 
>> there.
>>
>> As for a public place: I would _very_ much appreciate help with the 
>> API, although
>>
>> QUESTION FOR BIORUBY COMMUNITY AND DEVELOPERS:
>> * Do you think it would be best to create a sourceforge project for 
>> this, or should I add it directly into bioruby (e.g.
> Bio::Api::Ensembl)?
>> I suppose the second option would be best, but the stuff I have is 
>> probably not polished enough yet... and *far* from complete.
>> * Secondly: if a new release is coming: would it be best to wait 
>> untill _after_ that release?
>>
>> jan.
>>
>>
>> -----Original Message-----
>> From: Michael Han [mailto:mh6 at sanger.ac.uk]
>> Sent: 10 May 2007 09:51
>> To: jan aerts (RI)
>> Subject: Re: [BioRuby] Ensembl API
>>
>>
>> On 10 May 2007, at 08:58, jan aerts ((RI)) wrote:
>>> Michael,
>>>
>>> As you mention that we maybe won't be able to cover everything with 
>>> the default activerecord behaviour: what problems are you thinking
> of?
>>>
>>> Note: I'd like to use the perl API as a guide. And indeed working 
>>> out
>
>>> the Slice object was quite simple...
>>
>> Yes, I was thinking of the slices in combination with the different 
>> assembly levels.
>> A change to the mapping part of that broke the last EnsEMBL release.
>> There were some cases where a seq_region maps one-to-many to other 
>> seq_regions (also with gaps).
>> Did you put all the caching stuff from the Perl API into it? And if 
>> not, is the performance ok?
>>
>> It would be also great if you could put the code into some public 
>> place (RubyForge as example), then it would be easier to see what is 
>> already working/being worked at and what not.
>>
>>> jan.
>>>
>>> -----Original Message-----
>>> From: Michael Han [mailto:mh6 at sanger.ac.uk]
>>> Sent: 09 May 2007 14:38
>>> To: jan aerts (RI)
>>> Subject: Re: [BioRuby] Ensembl API
>>>
>>> On 9 May 2007, at 14:14, jan aerts ((RI)) wrote:
>>>> Has anyone worked on an Ensembl API? There is a perl API and the 
>>>> database schema is well-documented. On first impression, it seems 
>>>> straightforward to make one using ActiveRecord, but I wouldn't want

>>>> to
>>>
>>>> waste efforts on that if someone else is already working on it.
>>>>
>>>> See http://www.ensembl.org/info/software/core/index.html
>>>>
>>>> Dr Jan Aerts
>>>> Bioinformatics Group
>>>
>>> Hi Jan,
>>>
>>> I am not sure if you can cover everything with a the default active-

>>> record behavior.
>>> But I would be a happy user of a ruby EnsEMBL API.
>>> If you need/want help with it, I would also volunteer.
>>>
>>> Michael
>>
>