Hi Michael,

You could do it that way.  As long as you made a new object type and 
wrote supporting methods that would work.  And we designed it so that 
this could work, but I would still actually recommend another slightly 
different approach.

My preference would be to make 1) a function that takes a named list of 
data.frames and generates a simple org database.  (This is actually a 
pretty straightforward function to write).  And then 2) another function 
to call that and wrap that DB in an org package (also straightforward).  
The reason for this, is that by writing these two functions, you would 
1) get all the OrgDb objects methods for free since you would have made 
a package that creates an existing OrgDb object. (so no need to 
implement select and it's friends, and no need to introduce any new 
object types) and 2) We would maintain a consistent database schema with 
existing org packages.  This would help prevent the unnecessary 
proliferation of DB schemas and associated methods.  Those methods may 
be simple enough to implement, but it's really much better to not have 
to have to maintain multiple variations of them if you don't need to.  
The current schema for org packages is actually very simple and pretty 
general so it is almost trivial to make a DB of this kind.

Of course, for this strategy to make any sense whatsoever, you need to 
have data the needs to at least resemble what is normally found in an 
org package.  If your data is really very different from that, then your 
initial approach (which involves another supporting another different 
kind of object) could be more appropriate.


  Marc



On 05/23/2013 09:54 PM, Michael Lawrence wrote:
> Thanks, Marc.
>
> So it sounds almost trivial? to implement the select API on top of a 
> data.frame, where there is a single keytype corresponding to the row 
> names. We could make select, etc, methods for data.frame and/or 
> DataFrame and then my simple use case would be easy to achieve.
> Or am I missing something?
>
> Michael
>
>
>
> On Thu, May 23, 2013 at 5:51 PM, Marc Carlson <mcarlson@fhcrc.org 
> <mailto:mcarlson@fhcrc.org>> wrote:
>
>     Hi Michael,
>
>     As usual, Martin is on the right track.  The new Schema .pdf stuff
>     is only if you really need the old school bimaps, and bimaps are
>     not actually needed for any of the OrganismDbi stuff.  So the
>     interface of keytypes, cols, keys and select really ought to be
>     enough to allow integration into OrganismDbi...
>
>     And, if you also followed the same org package DB schema that we
>     use everywhere else that would be ideal since in that case, you
>     could just recycle the methods we have already defined for OrgDb
>     objects...  So in order to do that, a biomart equivalent to
>     AnntotationForge:::makeOrgDbFromNCBI() and
>     AnntotationForge:::makeOrgPackageFromNCBI would be a nice addition.
>
>     And I agree that a simple data.frame() based underlying
>     implementation would make this easier to generalize.  Right now
>     things are a bit specialized for NCBI resources.
>
>
>       Marc
>
>
>
>
>     On 05/17/2013 09:56 PM, Michael Lawrence wrote:
>
>         Cool, thanks Martin. I'll wait for Marc to get back. If what
>         you say is
>         correct, it would be nice to have a simple data frame
>         implementation. I'm
>         getting the annotations from a biomart, so a biomart
>         implementation would
>         be ideal, although that might be tricky semantically.
>
>         Michael
>
>
>
>
>         On Fri, May 17, 2013 at 5:43 PM, Martin Morgan
>         <mtmorgan@fhcrc.org <mailto:mtmorgan@fhcrc.org>> wrote:
>
>             On 05/16/2013 01:50 PM, Michael Lawrence wrote:
>
>                 Hi,
>
>                 I'd like to create an OrganismDbi package so that I
>                 can put extra
>                 annotations on the transcripts/genes in a TxDb
>                 package. My understanding
>                 is
>                 that I need a separate database package that I can
>                 join with the TxDb
>                 package. Do I need to make an OrgDb package? I looked
>                 into this a bit and
>                 it seems that there is little support for making a
>                 non-NCBI-based org
>                 package. Maybe I could create a new type of package
>                 with a simple table
>                 with a row for each transcript, including the gene
>                 symbol and whether the
>                 transcript is "canonical" according to UCSC. It looks
>                 like this process is
>                 documented here:
>                 http://www.bioconductor.org/**packages/2.12/bioc/vignettes/**
>                 AnnotationForge/inst/doc/**NewSchema.pdf<http://www.bioconductor.org/packages/2.12/bioc/vignettes/AnnotationForge/inst/doc/NewSchema.pdf>
>
>
>                 .
>                 It also seems really involved. What's the path of
>                 least resistance here?
>
>             Hi Michael -- Marc is away for a few days. I *think* the
>             idea is that the
>             details in NewSchema are no longer required, rather,
>             implement your extra
>             data in any fashion to provide a 'select' interface, i.e.,
>
>                keytypes
>                keys
>                cols
>                select
>
>             following the implied API of ?keytypes. Then create an
>             OrgDb package with
>
>                AnnotationDbi::**makeOrganismPackage
>
>
>             Sorry not to be more definitive in my help.
>
>             Martin
>
>
>                 Thanks,
>                 Michael
>
>                          [[alternative HTML version deleted]]
>
>                 ______________________________**_________________
>                 Bioconductor mailing list
>                 Bioconductor@r-project.org
>                 <mailto:Bioconductor@r-project.org>
>                 https://stat.ethz.ch/mailman/**listinfo/bioconductor<https://stat.ethz.ch/mailman/listinfo/bioconductor>
>                 Search the archives: http://news.gmane.org/gmane.**
>                 science.biology.informatics.**conductor<http://news.gmane.org/gmane.science.biology.informatics.conductor>
>
>
>             --
>             Computational Biology / Fred Hutchinson Cancer Research Center
>             1100 Fairview Ave. N.
>             PO Box 19024 Seattle, WA 98109
>
>             Location: Arnold Building M1 B861
>             Phone: (206) 667-2793 <tel:%28206%29%20667-2793>
>
>                 [[alternative HTML version deleted]]
>
>         _______________________________________________
>         Bioconductor mailing list
>         Bioconductor@r-project.org <mailto:Bioconductor@r-project.org>
>         https://stat.ethz.ch/mailman/listinfo/bioconductor
>         Search the archives:
>         http://news.gmane.org/gmane.science.biology.informatics.conductor
>
>
>


	[[alternative HTML version deleted]]

