[BioSQL-l] Seqfeature_Source

[Thomas Down]

On Thu, Sep 19, 2002 at 11:05:58AM -0700, Hilmar Lapp wrote:
> >>>Couple of note:
> >>>
> >>>  - I'm not hard nosed about this, and am open to persuasion
> >>>    (especially if it really does make things run a lot faster).
> >>>
> >>
> >>My point is not only about this being potentially faster. My point
> >>was more targeted at the present design being non-intuitive, and not
> >>justified by any of the Bio* object models AFAIK.
> >
> >Do you expect many people to be writing code which talks directly
> >to BioSQL?
> 
> Yes and no. First I believe every other use case than round-tripping 
> eventually calls for the ability to issue more complex queries. What 
> the adaptors allow you to do is not necessarily going to be enough, 
> or fast enough. Data mining through adaptor calls is a nice idea, 
> but will need the adaptors to evolve a way. Until then, you'll want 
> to write and test SQL queries.

Hmmm, I'm definitely a data-mining-through-the-adaptors person.
BioJava has a kind of query language called FeatureFilters,
which allow you to do a reasonable amount of data mining
without dropping to SQL (when you query a FeatureFilter against
BioSQL, the adaptor will usually compile it into an underlying
SQL query).  We want to build on this with a more fully-featured
(but still independant of the underlying storage model) query
system in BioJava2.

> Counter-intuitiveness also hits people who (want to) join adaptor 
> code development (like me myself :) ...

True.  I'm not arguing for making things purposefully awkward,
don't worry...

> >What do you mean by this?  Are you suggesting having a bridge
> >table such that any seqfeature can be associated with any number
> >of ontology_terms?
> 
> Yes.
> 
> >  In principle, that might not be such a bad
> >idea, but I don't think it fits the object models for any of
> >the current Bio* projects.  It's a little closer to some proposed
> >stuff for BioJava2, but still not quite the same...
> >
> 
> What it would basically reflect is that SeqFeatures are annotatable, 
> too. Not with objects though, but with terms.
> 
> Aren't seqfeatures annotatable in BioJava?

Yes, they are.  However, the annotation is of a key-value
sort (Object -> Object in memory, String -> {String or List<String>}
in SQL).  We persist this in the seqfeature_qualifier_value table
of BioSQL.

The keys of the key-value pairs are ontology_terms, so it all
comes down to the same kind of thing in the end.

I guess there's an argument for making the value part of
the key-value stuff NULLable (if it isn't already), so you
can do straightforward keyword-type annotation that way.

     Thomas.